XML

Word

Printable

Epic Name:
Investigation for add-on owners to tolerate differing API versions between hub and managed cluster
Blocked:
False
Blocked Reason:
None
Ready:
False
Color Status:
Not Selected
Epic Status:
To Do
Hierarchy Progress Bar:

0% To Do, 0% In Progress, 100% Done

Epic Goal

As part of the larger goal defined in https://issues.redhat.com/browse/ACM-1717, we need each add-on maintainer to investigate the implications of the hub control plane version differing from their add-on version on the managed cluster.

Why is this important?

We need to ensure that add-ons operator smoothly as a rolling upgrade is performed. Add-on owners, especially those that rely on replication, need to understand how their agent components will function when their APIs are on differing versions or their CRDs are not in sync.
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.

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

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>