Epic Goal

• Provide a convenient  way to migrate from a homogeneous to a heterogeneous cluster.

Why is this important?

• So customers with an existing cluster can migrate to a heterogeneous payload rather than doing a fresh install, without needing to use oc adm upgrade --allow-explicit-upgrade --to-image "${PULLSPEC}".  OTA-658 and maybe some oc side tooling, if folks feel oc patch ... is too heavy (although see discussion in OTA-597 about policies for adding new oc subcommands).

• So components (like which?) can make decisions (like what?) based on the "current" cluster architecture. OTA-659.

Scenarios

1. Upgrade from a homogeneous release eg. 4.11.0-x86_64 to a heterogeneous release 4.11.0-multi.
2. Ensure that ClusterVersion spec has a new architecture field to denote desired architecture of the cluster
3. Ensure ClusterVersionStatus populates a new architecture field denoting the current architecture of the cluster.

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.    Should the migration also be an upgrade or should it be two separate steps? i.e, migrate to hetero release of same version and then upgrade?

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>