Epic Goal

Design how skip-level updates (which OCPSTRAT-2638 is aiming to deliver for Classic/standalone) could work for HyperShift.

Why is this important

Kubernetes introduced compatibility versioning (KEP-4330). It's currently alpha. Once it becomes beta and delivers useful skew, there's interest in delivering that functionality in OpenShift. OCPSTRAT-2638 currently has "Not in phase-1" for HyperShift work, while it focuses on Classic/standalone clusters.  This Epic tracks the design work to plan out how we will expand the functionality to HyperShift in later phases.  Currently as a child of OCPSTRAT-2638, because I'm not aware of an OCPSTRAT aimed at skip-level updates for HyperShift, but we can move this ticket to such an OCPSTRAT if/when it is created.

Scenarios

Apply a skip-level update of at least one HyperShift cluster from 5.2 to 5.5. The update should complete smoothly without touching 5.3 or 5.4 bits. Versions are an example; feel free to negotiate if this is a larger lift that needs more lead time or team capacity.

Standalone is a separate, and covered in OCPSTRAT-2638.

Dependencies

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

Standalone is a separate, covered in OCPSTRAT-2638, and will precede the HyperShift work. This Epic's HyperShift design work can wait on that standalone work to gain experience with skip-levels, or happen in parallel, depending on how folks want to balance delivery efficiency vs. speed.

Some other teams may need to collaborate on the design, e.g. talking about how feasible it would be to shift logic from the HyperShift control-plane operator out into HyperShift-aware controllers (e.g. OTA-951 might allow the CPO to offload some of its management to the CVO, to get a more ordered update flow even among management-cluster-side components).

Acceptance criteria

OCPSTRAT Features and Epics created to deliver the design that this Epic produces.

Drawbacks and risks

Sinking work into design an implementation here could be wasted if the upstream KEP or OpenShift standalone work is abandoned before it becomes a generally-available feature. Waiting too long before investing in HyperShift design could delay customer access to this functionality. Somewhere in the middle, there's hopefully a sweet spot for HyperShift design work to happen .

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