Epic Goal

Folding the Upgradeable condition in as a conditional update risk in ClusterVersion and the cluster-version operator, so users can use the more-explicit availableUpdates and conditionalUpdates properties without having to internalize the Upgradeable condition's semantics.

What is our purpose in implementing this?  What new capability will be available to customers?

Users frequently get confused about the scope of the Upgradeable condition. Which is fair, given the very specific semantics compared with the generic name. Popular misconceptions include:

• Folks thinking it is relevant to a currently in-progress update. This is getting addressed in the oc adm upgrade status command (tech-preview since 4.16, OTA-1114) and API (ongoing, OTA-1260), which do not talk about Upgradeable.
• Folks thinking it is relevant to 4.y.z to 4.y.z' patch updates, when (outside of ClusterVersion overrides) it's only about 4.y to 4.(y+1) patch updates.

In OTA-902's oc#1907, we folded Upgradeable in as a conditional risk in the tech-preview-since-4.18 oc adm upgrade recommend command. This epic is about lifting that logic from the client-side into the CVO, so more consumers can benefit from the change, and so we can do a crisper job on the implementation (e.g. the current client-side code is not aware of the "overrides also block patch updates" wrinkle, but the CVO is the owner of those opinions, so it could handle that case easily).

Why is this important?

Reducing confusion in ClusterVersion consumers (both end-user cluster admins and tooling like HyperShift and OCM that build on top of the API) will reduce the number of bugs and support discussion caused by misunderstanding the Upgradeable API.

Scenarios

As a ClusterVersion consumer with a 4.y cluster interested in 4.y updates, I'm not distracted by the cluster's concerns about 4.(y+1) releases.

As a ClusterVersion consumer whose already used to consuming availableUpdates and Upgradeable, but who hasn't yet caught up with 4.10's conditionalUpdates, I'm not left thinking that there are not updates and there's nothing I can do, when in fact the Upgradeable issues are something I'm supposed to act on.

As a ClusterVersion consumer who prefers launching --to-image updates in a disconnected/restricted-network environment, I want some kind of heads up that a 4.y to 4.(y+1) update might get rejected.

Dependencies

Probably want to loop in the web-console folks to tweak the update-selection interface with conditionalUpdates becoming something we want to be more directly promoting, similar to the changes OTA-1270 made in working up the recommend command.

Contributing Teams

• Development - OTA, CONSOLE
• Documentation - OTA
• QE - OTA
• PX - OTA
• Others -

Acceptance Criteria

Web-console and ClusterVersion status make it more obvious that 4.y.z to 4.y.z' updates are not exposed to Upgradeable issues.

Drawbacks or Risk

We've survived since 4.3 with the current Upgradeable API and UX. We can probably continue to handle the rate of confusion if we can't afford the time to develop this yet.

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