-
Epic
-
Resolution: Unresolved
-
Undefined
-
Future
-
None
Epic Goal
As an MCO Fleet administrator, I am able to assess the health and performance of my MCOA deployed components in high level Service Level Indicators that denote the health of critical API paths (Logs, Metrics, Trace/OpenTelemetry collection and storage)
Definition of Service Level Indicators
Why is this important?
- We need to provide simple metrics that a user can determine quality of service from
- This will become the basis of Service Level Objects and minimum levels of service we will guarantee to a user on ACM
- Currently it's not clear to user when they should raise a support issue and when issues in their cluster should be escalated to us or remediated by a self-service scale event
Scenarios
Example RHOBS SLOs for Metrics
Acceptance Criteria
...
Dependencies (internal and external)
- ...
Previous Work (Optional):
- ...
Open questions:
- …
Done Checklist
- CI - CI is running, tests are automated and merged.
- Release Enablement <link to Feature Enablement Presentation>
- DEV - Upstream code and tests merged: <link to meaningful PR or GitHub
Issue> - DEV - Upstream documentation merged: <link to meaningful PR or GitHub
Issue> - DEV - Downstream build attached to advisory: <link to errata>
- QE - Test plans in Polarion: <link or reference to Polarion>
- QE - Automated tests merged: <link or reference to automated tests>
- DOC - Doc issue opened with a completed template. Separate doc issue
opened for any deprecation, removal, or any current known
issue/troubleshooting removal from the doc, if applicable.
