Epic Goal

• Customers need to know what is included in RHACM at the hub and at the managed cluster.
• Customers need a better understanding of the RHACM architecture at the component level.
• Customers are asking for more clarity about what images are leveraged for each RHACM component.
• RHACM DOC used to cover this topic, example from RHACM 2.1: https://access.redhat.com/documentation/en-us/red_hat_advanced_cluster_management_for_kubernetes/2.1/html/about/welcome-to-red-hat-advanced-cluster-management-for-kubernetes#components

Why is this important?

• In order to provide better serviceability to the customer, we need to provide clear documentation about the components we deliver.
• Customers need sign-off from security teams and this level of component description is necessary.

Scenarios

1. As a RHACM customer, I need to see what components are included in a particular released version of RHACM.
2. As a Security team, I need to review all of the shipped components and their related images in the RHACM payload in order to be in an audit-ready posture.

Acceptance Criteria

• CI - MUST be running successfully with tests automated
• Release Technical Enablement - Provide necessary release enablement details and documents.
• Documentation of the RHACM components - full list at the time of release.

Dependencies (internal and external)

1. ...

Previous Work (Optional):

1. …

Open questions:

1. How best to maintain this list from release to the next?

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>