Epic Goal

Deliver visualizations for right sizing recommendations which can illustrate the trend of CPU/MEM consumption over time.

Why is this important?

Platform engineering requires an outlook into the forecasted needs of infrastructure. Budget allocations determined by CTO will rely on accurate information from the platform architect(s). Platforms cost money at the end of the day, and we need to be able to help ensure Red Hat customers continue to use the provided tooling to perform budget and capacity planning rather than move to adjacent vendors which could eventually detract customers away from their Red Hat purchase.

Seeing this information builds confidence that we understand the platform usage and the recommendations being offered.

Scenarios

As a platform engineer, I need to see recommendations about where I can right-size my clusters based on request & limit information when compared to actual usage.

I need to be able to see the historical trend, 30d/60d/90d, to understand if the workload is consistently under the recommendation or if we need to account for some peaks and time periods of high-loads.

As a developer, I need to have a clear picture of my project usage and my app/container level usage.  A visual is necessary to prove to me that I have to change my code. Otherwise I do not believe the platform team has the right information to guide me.

Acceptance Criteria

A visual experience for right sizing recommendations should include a performant visual experience eg, within 5 seconds to load the data.
Otherwise, we need to evaluate delivering as a scheduled report that can run during off-peak hours and the recommendation visuals can be delivered via eg, slack, email.

Dependencies (internal and external)

1. We depend on Kuberenetes right sizing work with ACM Observability.

Previous Work (Optional):

1. ...

Open questions:

1. …

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 - Downstream documentation merged: <link to meaningful PR>