Epic Goal

• We need to publish a cincinatti upgrade graph/channel for the new multiarch payloads.

Why is this important?

• So customers have a directed upgrade path when running multiarch payloads

Scenarios

1. There will only be one multiarch payload (i.e. we will not have a unique payload for each possible combination of architectures, we will ship one payload that has all the architectures in it), so we need one new graph/channel.

Acceptance Criteria

•  Heterogeneous clusters should be able to get available update information from OSUS and should be able to update to a different version (heterogeneous payload version)
• CI - MUST be running successfully with tests automated
• Upgrade graph exists, clusters subscribed to the appropriate channel get a recommended payload image upgrade suggestion. The graph gets updated as we publish new z+minor releases.

Open questions::

1. The initial attempt to publish a multiarch payload to quay broke cincinatti when it scanned the repo and saw the new payload. We need to understand what broke and why so we can make Cincinnati tolerant of these payloads.

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>