Add "service-type" dimension to collection of calculated concurrent usage
Summary
As the Tally service, I want to understand how many concurrent RHEL instances are running via any existing combination of reported attributes plus any known combination of syspurpose "service-type" values so that I can provide maximum filtering and presentation capabilities to the end user.
Swatch/Tally folks have expressed interest in adding the syspurpose service-type values to our concurrent API output. This would add service-type as another dimension to that process, and the resulting set of counts would expand to include counts "for each arch for each role for each sla for each usage for each service-type".
Acceptance Criteria
-
Verify concurrent usage API output includes any existing combination of arch/SLA/Role/Usage combined with any Service Type value relevant to the instances and time period. -
Verify openapi.json includes the new Service Type in the concurrent usage API's response.
-
-
QE will expand the existing integration tests to include checking for the new Service Type values. -
Verify that IQE client for cloudigrade is updated with any new openapi.json changes.
-
Assumptions and Questions
- As a reminder, syspurpose contents could be written arbitrarily by the end user. So, we should continue to dynamically explode the set of values we encounter to our results.
- We currently truncate to 64 characters for each of the syspurpose attributes. We have no special handling for non-ASCII/Latin1-safe characters, but we should handle the normal Unicode/UTF-8 set.
- Where does this value live? Is is a new part of
syspurpose.json? What are some typical expected values?- See also: Google Doc: Syspurpose Service-Type
Edited by Maribeth Pierce