Epic Goal

Currently we sometimes get questions like "why don't I see 4.y.z in my stable-4.y cluster yet?" or "why doesn't my 4.y.z stable-4.y cluster have opinions on a 4.(y+1).z' release?".  We want to make it easier for cluster admins to self-serve that answers by including cluster-version operator opinions of any possible next-hop target, regardless of whether that next-hop is in the cluster's current channel or not.

Why is this important?

Customer will be more likely to understand that a supported update is possible today, without waiting for a release to percolate through to stable channels.

As a subset of the customer benefit, this would make it easier for managed OSD/ROSA (which currently use a stable-4.y channel for a 4.y.z cluster) to understand whether a 4.(y+1).z update would be recommended in stable-4.(y+1) or not.

Red Hat support/developers will have less work fielding questions to manually supply that context.

Sets some ground-work for future work on update policies (OCPSTRAT-1279), where we'll want cluster-version operator opinions on next-hop update targets in the various policy buckets regardless of the cluster's current channel.

Scenarios

In the stable-4.19 channel, a 4.19.0 cluster will have conditionalUpdates information about a new 4.19.z that's currently only in fast-4.19, and even newer 4.19.z' that's currently only in candidate-4.19, and a 4.20.z that's currently only in fast-4.20. All of those would be guarded by at least a DifferentChannel update risk, to keep the cluster admin from updating without realizing that the target was not in their current channel.

Dependencies (internal and external)

The Over the Air Updates team can unilaterally deliver the cluster-version operator work for testing. If testing is positive, the OTA team can deliver oc adm upgrade ... changes like OTA-1270, and work with the OCP-web-console team and out-of-cluster teams like ACM and OCM to make any related UI adjustments.

Contributing Teams(and contacts)

The Over the Air Updates (OTA) team can unilaterally deliver the cluster-version operator work for internal testing, which is the target of this epic.

If testing is positive, future work can track:

• The OTA team delivering oc adm upgrade ... changes like OTA-1270.
• The OTA team, and work with the OCP-web-console team and out-of-cluster teams like ACM and OCM to make any related UI adjustments.

Development, docs, QE, and PX involvement would be needed from each team for that follow-up work.

Acceptance Criteria

The Scenarios section has a testable example, and we can use mock update services (OTA-520) to perform testing pre-merge and during the Engineering Candidate and Release Candidate phases of development.

Drawbacks or Risk

If we build this and decide not to proceed further in that direction, we'd have wasted time on CVO work that we later rip out. Decisions about make this approach Generally Available are deferred to later work, so there is no immediate risk of post-GA drawbacks in this Epic.

Done - Checklist

The following points apply to all epics and are what the OpenShift team believes are the minimum set of criteria that epics should meet for us to consider them potentially shippable. We request that epic owners modify this list to reflect the work to be completed in order to produce something that is potentially shippable.

• CI Testing - Tests are merged and completing successfully
• Documentation - Content development is complete.
• QE - Test scenarios are written and executed successfully.
• Technical Enablement - Slides are complete (if requested by PLM)
• Other