Epic Goal

Kubernetes introduced compatibility versioning (KEP-4330). It's currently alpha. Once it becomes beta and delivers useful skew, this Epic calls for that functionality to be delivered by OpenShift's Kube API server, as part of allowing for things like skip-level updates (OCPSTRAT-2638).

Why is this important

For cluster-admins, skip-level updates would allow for updates with a longer stride, removing the current need to mirror and run intermediate releases. For example, today, and update from 4.12 to 4.14 requires running an intermediate 4.13 release. With skip-level updates, a cluster-admin could potentially jump straight to the target release without touching intermediate bits (although the emulation version handling would still have them touching intermediate APIs).

For Red Hat, skip-level updates would allow us to stop releasing end-of-life intermediate releases. For example, we are still building occasional 4.13.z patches to give customers on the EUS 4.12 a path to 4.14, even though 4.13 itself went end-of-life on 2024-11-17.

Scenarios

Apply a skip-level update of at least one happy-path cluster from 5.0 to 5.2. The update should complete smoothly without touching 5.1 bits.

Guards for clusters not on the happy path are covered in OTA-253 and OTA-1793 and are separate from this Epic.

Dependencies

KEP-4330 is currently alpha, and needs to be at least beta before we'd tech-preview this functionality.

Some other teams may need to shift manifests that currently appear before the the Kube API server in the ordered update manifest task-node graph to occur behind the Kube API server. Possibly etcd (currently a sibling of KAS at runlevel 20) should move to a later level as well.

The Kube API server and config operator are both owned by this team, but in order to ratchet through the intermediate release APIs with --emulation-version, the config operator may need to learn what OpenShift feature-gates were enabled in which feature sets in the intermediate release and persist that information into the cluster, so KASO could figure out how to run the intermediate APIs while ratcheting. If this needs to happen, it could be delivered as part of this Epic, or sharded out into a sibling CNTRLPLANE Epic.

Acceptance criteria

Apply a skip-level update of at least one happy-path cluster from 5.0 to 5.2. The update should complete smoothly without touching 5.1 bits.

Drawbacks and risks

Sinking work into design an implementation here could be wasted if the upstream KEP is abandoned before it becomes a generally-available feature upstream.

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