Epic Goal

• Define SLIs for components that will be used by Service Delivery.
• Code instrumentation for agreed upon SLIs, expose metrics.
• Define alerting rules for SLIs.
• Determine starting SLO based on aggregation of our SLIs.

Why is this important?

• Meet SLA requirements that will be established as part of SD.
• Service monitoring and alerting will be essential for quick RCA and resolution for service disruptions across environments.

Scenarios

1. ACM health pre and post install/upgrade
2. Hypershift Addon and its installer components
3. Policy controllers, but not the actual policy being applied
4. Foundation components

Acceptance Criteria

• CI - MUST be running successfully with tests automated
• Release Technical Enablement - Provide necessary release enablement details and documents.

Dependencies (internal and external)

1. Hypershift-addon

1. 1. agent addon
   2. agent Hypershift-operator
   3. agent External DNS
2. Policy
   1. All controllers
   2. agents
3. Foundation
   1. Hub side controllers
   2. Agent side controllers

Previous Work (Optional):

1. Server Foundation F2F 2022 discussion
   • https://docs.google.com/document/d/1sJcf8_Rgxb1FX9VfD-Hl_7y4XM8zCf00BYW5NtLWDZg/edit# 
2. Hypershift addon document
   • https://docs.google.com/document/d/1wnj49GoBMxez-bnDJ-Qz3WR3bptNssoetyA8NdXeYuw/edit?usp=sharing

Open questions::

1. Are there a set of signals SLI's that service devivery requires or suggests?
2. How many of the signals can be just rules? (no code change required)

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{}