Epic Goal

The OpenShift Update Service should set a DifferentChannel update risk for 4.y.z update targets that are single-hop updates from the client's current version but in a channel that's not the client's current channel.

Why is this important?

Some cluster administrators do not actively manage their channel, but still want to know about whether a particular 4.y.z next-hop target is exposed to declared update risks that are relevant to their cluster.

For example, ROSA uses version-agnostic channel groups like stable, which the managed upgrade operator rehydrates to a version-capped channel using the cluster's current 4.y. That means that Classic ROSA clusters only set their channel from stable-4.y to stable-4.(y+1) after the cluster administrator has selected a particular 4.(y+1).z update target that they want to move towards.

And many cluster admins, both self-managed and on managed offerings, sometimes sometimes ask questions like "why don't I see updates to 4.y.z?" when 4.y.z is in candidate-4.y or fast-4.y but not yet in the stable-4.y channel the admin has configured for that cluster. We want oc adm recommend ... (which is getting an initial implementation under OTA-1270) to be able to say things like "updates to 4.y.z are possible now in fast-4.y, but not in your current stable-4.y" so admins can self-serve that information more conveniently (and without having to set fast-4.y as their cluster's channel, although I'm not entirely clear on why changing the channel like that would be a problem).

In these cases, Cincinnati could assist by setting a DifferentChannel update risk for 4.y.z update targets that are single-hop updates from the client's current version but in a channel that's not the client's current channel. I mocked that out client-side in the CVO in OTA-1301, but moving the logic to Cincinnati would:

• Make it easy to adjust the risk declaration if we wanted to refine messaging. With a CVO-side implementation, we'd have to land adjustments in the CVO, release new versions of OCP based on that new CVO code, and wait for customers to update their clusters before they saw the new messaging.
• Provide backwards compatibility with the existing fleet. We can teach Cincinnati about this today, and all existing clusters since conditional risks became a thing in 4.10 will be able to present the context to their cluster admins.

Scenarios

Users do not have to change any behavior for this, but they will benefit from the increased context in ClusterVersion status.conditionalUpdates. For users poking around in that space (directly, or via oc adm upgrade, or the in-cluster web-console or HostedCluster's status.version.conditionalUpdates, etc.), having that context assembled for them might head off them having to ask around while building that context more manually.

ROSA customers will also benefit if OCM consumes this information and uses it to populate next-hop update release options. They may get the additional "it's GA in OCP-core, but not yet in your stable channel" context, if OCM opts to expose that message, XCMSTRAT-513. And they may get per-cluster assessments of other declared update risks in 4.(y+1).z update targets (as long as ROSA's use of version-agnostic channel groups keeps cluster admins from being able to say they want to be in stable-4.(y+1).

Dependencies

The OCP updates team can deliver the Cincinnati changes without needing assistance from other teams.

OpenShift Update Consumers are already familiar with the conditionalEdges / conditionalUpdates API, and it's possible for them to ignore that API property entirely. That isn't changing with this Epic, so we don't need to negotiate client-side changes as part of rolling this out.

Contributing Teams (and contacts)

• Development - OTA
• Documentation - OTA
• QE - OTA
• PX - OTA
• Others - None

Acceptance Criteria

A 4.12.62 cluster in eus-4.12 will see update recommendations to 4.13.49 in conditionalUpdates that are Recommended=False with a message that at least mentions the DifferentChannel risk.

Drawbacks or Risk

Cincinnati changes take time and effort. It's not particularly clear why ROSA is committed to version-agnostic channel groups, or why customers impatient for a 4.y.z release won't try fast-4.y. Perhaps with better messaging, we could move ROSA and the impatient customers towards approaches compatible with the current Cincinnati behavior. But so far we have not had much luck trying to shift that behavior, and this seems like a limited-dev cost that might resolve the disconnect by meeting users closer to where they are today.

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