Epic Goal

Contrary to SemVer expectations, 4.22 to 5.0 updates are not expected to include backward incompatible changes that require clusters to be re-installed. In order to support those updates, the 4.22 cluster-version operator should relax its giant-hop guard that currently blocks major-version bumps. It should also adjust the Upgradeable condition handling to treat 4.22 to 5.0 as if it was the same as a 4.22 to 4.23 minor-version bump.

This should happen early in 4.22 development, in case there are 4.22.0-ec.* to 5.0.0-ec.* updates for any folks kicking the tires early, even though that means we might need to have the change in the development branch and revert it later.

The 5.0 target should be special-cased, e.g. updates from 4.22 to 5.1, or from 5 to 6, etc., do not need to be allowed in the 4.22 code. If we decide those are going to be supported in the future, we can make further adjustments to the guardrails at that time.

There is no need for guards to distinguish between updates to 4.23 and updates to 5.0. As far as the 4.22 cluster is concerned, 4.23 and 5.0 can be considered synonymous.

Why is this important?

Users should be able to update from 4.22 to 5.0 with an experience similar to existing 4.y to 4.(y+1) updates, without having to force through guardrails. They may still need to make alterations to their 4.22 cluster to address Upgradeable guards, such as ack-ing admin-acks, confirming manual credentials are compatible with the target version, etc., but those have traditionally been part of 4.y to 4.(y+1) updates.

Scenarios

A 4.22 cluster should be able to update to 5.0 releases without having to force through the giant-hop or Upgradeable=False guardrails.

Dependencies

No dependencies outside the CVO for the giant-hop relaxation or the Upgradeable=False applicatoin. There will be other components that need to make their own changes to 4.22 code to support the overall OCPSTRAT-2797 initiative, and some of that work may involve updating components that set ClusterOperator Upgradeable conditions that the CVO consumes.

Contributing Teams

• Development - OTA
• Documentation - not required
• QE - OTA
• PX - not required
• Others - not required

Acceptance Criteria

Updates from 4.22 nightlies to 5.0 nightlies no longer bump into "only updates within the current major version are supported" wording.

Injecting a new admin-gate for ack-4.22-testing-in-5.0-and-4.23 will create a guard that blocks unforced updates to 5.0 and 4.23 targets, and the guard can be addressed with the usual admin-acks sign-off.

Drawbacks or Risk

Not distinguishing between 5.0 and 4.23 targets limits our flexibility in what changes go into which of those releases. E.g. if we add something that needs pre-update preparation to 5.0, users intending to update to 4.23 will have to do that preparation work before updating to 4.23, even if 4.23 doesn't actually need that preparation. We could build a more nuanced guard system that did allow that kind of distinction, but because we are not aware of any 5.0/4.23 divergence plans at the moment, we are recycling the existing tooling to save on development costs.

Done - Checklist

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