Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

GET /deliveryservice_stats limits metric types #4740

Closed
2 of 16 tasks
mitchell852 opened this issue May 29, 2020 · 1 comment · Fixed by #4742
Closed
2 of 16 tasks

GET /deliveryservice_stats limits metric types #4740

mitchell852 opened this issue May 29, 2020 · 1 comment · Fixed by #4742
Labels
regression bug a bug in existing functionality introduced by a new version Traffic Ops related to Traffic Ops

Comments

@mitchell852
Copy link
Member

mitchell852 commented May 29, 2020

I'm submitting a ...

  • bug report
  • new feature / enhancement request
  • improvement request (usability, performance, tech debt, etc.)
  • other

Traffic Control components affected ...

  • CDN in a Box
  • Documentation
  • Grove
  • Traffic Control Client
  • Traffic Monitor
  • Traffic Ops
  • Traffic Ops ORT
  • Traffic Portal
  • Traffic Router
  • Traffic Stats
  • Traffic Vault
  • unknown

Current behavior:

The Go version of GET /deliveryservice_stats limits the metric types to the following:

dsMetricTypes = map[string]interface{}{
	"kbps":      struct{}{},
	"tps_total": struct{}{},
	"tps_2xx":   struct{}{},
	"tps_3xx":   struct{}{},
	"tps_4xx":   struct{}{},
	"tps_5xx":   struct{}{},
}

Therefore making it impossible to fetch metricType=foo for example. The Perl version did not restrict the metric types but rather it simply added whatever metric type to the influx query.

I would suggest fixing this in 1.x and 2.x (which is already part of TC 4.1) and potentially redesigning the entire endpoint for 3.x (which is part of TC 5.0). I'll created a separate issue for that - #4741

Expected / new behavior:

GET /api/deliveryservice_stats does not limit metric types to a predefined set.

Minimal reproduction of the problem with instructions:

GET /api/1.4/deliveryservice_stats?metricType=foo will return a 400 bad request.

@mitchell852 mitchell852 added bug something isn't working as intended Traffic Ops related to Traffic Ops regression bug a bug in existing functionality introduced by a new version labels May 29, 2020
@ocket8888
Copy link
Contributor

This was intentional. The Perl version allowed for arbitrary input without restriction, which let a read-only user destroy the entire stats database. I'd suggest that instead if there's a new type of stat you want, we just add support for that instead.

@mitchell852 mitchell852 removed the bug something isn't working as intended label Aug 28, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
regression bug a bug in existing functionality introduced by a new version Traffic Ops related to Traffic Ops
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants