OpenShift 4 Lifecycle Enhancements: Introducing an extended update support phase

Red Hat is making changes to the length of time for which a minor version release (4.y) of OpenShift 4 will be supported. Previously in October 2021 we first announced a move to timeline-based lifecycles whereby every release 4.y release from 4.6 onwards would have an 18 month lifecycle and we would designate every even numbered release of OpenShift an Extended Update Support (EUS) release with a focus on streamlining upgrades between these releases.

These designated Extended Update Support releases still had the same 18 month lifecycle attached to them as regular releases, but we said at the time if at some point in the future we were able to offer more than 18 months this would be attached to these releases. We are happy to announce that this previously hypothetical point in the future is now!

Effective starting with the OpenShift 4.12 release Red Hat is adding an additional 6 months of Extended Update Support phase on even-numbered OpenShift releases for the x86_64 architecture. This takes the total accessible support life-cycle for these OpenShift releases to 24 months. Expansion to include other architectures will be reviewed in subsequent Extended Update Support releases.

We are making this change to support the increasing number of customers taking OpenShift into environments with stringent requirements, often regulatory, around the management of upgrade cycles that severely restrict or preclude the consuming of more regular upgrades to the platform or make them cost prohibitive due to the number of moving parts in the overall solution. This change also supports the many Red Hat Partners serving these same customers as we build cohesive solutions together.

Who is this additional lifecycle phase available to?

This new additional lifecycle phase will be available to all customers with Premium subscriptions for OpenShift Platform Plus, OpenShift Container Platform, or OpenShift Kubernetes Engine (see Production Support Terms of Service for more information on Premium and Standard subscriptions). Alternatively those with Standard subscriptions will be able to purchase an Extended Update Support add-on. This makes OpenShift’s Extended Update Support offering consistent with the RHEL EUS offering customers may already be familiar with.

What does this mean for the support lifecycle of OpenShift 4.12?

As always the source of truth with regards to the OpenShift Lifecycle is the Red Hat OpenShift Container Platform Life Cycle Policy but by way of example:

• OpenShift 4.12 was released on January 17th, 2023.
• OpenShift 4.12 is in the full support phase until the release of OpenShift 4.13 + 3 months, when it will enter maintenance support.
• OpenShift 4.12 maintenance support ends July 17th, 2024, when it will enter the EUS phase for those customers with Premium subscriptions or Standard Subscriptions + the EUS add-on.
• NEW: OpenShift 4.12 Extended Update Support ends January 17th, 2025.

What changes will be made during the Extended Update Support phase?

During the Extended Update Support phase of designated OpenShift EUS releases, Red Hat provides backports of Critical and Important impact security updates (CVEs) and urgent-priority bug fixes for a predefined set of minor releases of Red Hat OpenShift. EUS enables customers to remain with the same minor release of Red Hat OpenShift for a total 24 months, allowing for stable production environments for mission-critical applications.

Does this lifecycle change apply to all layered operators shipped by Red Hat?

This immediate change applies only to the core OpenShift platform.  We recognize the customer need for further simplification and alignment for operator content and are constantly evolving, striving toward that goal.  The broader ecosystem around OpenShift is made up of a diverse set of offerings with varying levels of maturity and feature velocity.  To retain agility amongst distinct technologies and ensure we’re delivering features and maintainability where appropriate, a one size fits all life cycle applied to all operators is neither feasible, nor our objective.  At this time, it is recommended that customers continue to review the life cycle page for each operator they consume, and stay tuned for further enhancements in the coming OpenShift releases.

With a 24 month lifecycle EUS-to-EUS-to-EUS upgrades fit comfortably within the lifecycle whereas the current 18 month lifecycle made it difficult to achieve this pattern. What, if any, changes to the product will be made to enable upgrading across 3 or more versions at once?

No changes beyond the EUS-to-EUS update optimizations made available previously for the 4.8 to 4.10 upgrade process which allow worker nodes to effectively “skip” a release (and the associated reboot). OpenShift does however continue to work within the API compatibility constraints of Kubernetes, which requires sequential upgrades of the control plane through each Kubernetes version. This is not changing with the introduction of this expanded Extended Update Support offering. 

These two upgrades (e.g. 4.12 to 4.14 and 4.14 to 4.16 for example) would need to be considered independently, and we will advise customers that they should pause at each EUS version for no less than 1 hour but ideally 24 hours or longer. Additionally, customers should ensure that all external integration points are validated before moving forward through each step.

As with most distributed systems, this means there is an inherent tradeoff between frequently performing many smaller upgrades with associated minimal deltas between them, and performing less frequent large upgrades with larger deltas between them like those inherent in this scenario. It’s important to carefully weigh up which approach is more appropriate for your environment and operational constraints as part of planning your environment.

How does this impact when Kubernetes API changes occur in OpenShift?

Kubernetes API deprecations, and removals in OpenShift will continue to occur on OpenShift release boundaries aligned with when those changes occur in the underlying Kubernetes version (Kubernetes 1.25 in the case of OpenShift 4.12).

Commencing with OpenShift 4.9, Red Hat provides comprehensive documentation of such changes on a per version basis in the Navigating Kubernetes API deprecations and removals Knowledge Base article.