Epic Goal

• Provide an "umbrella" API in ACM that allows defining a desired rolling upgrade for Klusterlets and add-ons deployed across managed clusters.

Investigation Epic on determing the right API to provide this:  https://issues.redhat.com/browse/ACM-5650 

If TALM is decided, we need to figure out how to transfer this work to the TALM team.

Why is this important?

• Today, whenever ACM (MultiClusterHub operator) is upgraded, not only is the hub operator upgraded; but a fleet-wide upgrade of all Klusterlet and add-ons are initiated and performed simultaneously. Customers, especially in services and edge scenarios, need finer grained control over the upgrade process to minimize disruption and prevent problems getting introduced into their production environments that would impact their end-users.

Guiding Use Case Exploration Document

Scenarios

1. Group clusters for upgrade
2. Allow desired version to be configured
3. Status and feedback on upgrade progression
4. Date/time information on upgrade
5. Code instrumentation and metrics

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. ...

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>