Goal

By OCP 4.22, we have enabled support for upgrading from OCP 4.22 to OCP 5.0, but as of today, this might be blocked by explicit or implicit logic in our update management systems and API compatibility statements/settings.

Background:

In several places in the OpenShift core platform, release and product lifecycle tooling, assumptions have been made about compatibility and allowed update paths with only the OCP 4 major version line in mind. Update jumps to a newer OCP major version are currently gated, compatibility statements of APIs only encompass OpenShift 4.y releases, the literal number 4 may be hard-coded in several places.

As we are moving to OCP 5 with the overarching goal of keeping changes to the scope of another OCP 4.y minor update, we need to expand these compatibility statements and update paths and remove any implicit assumptions that OpenShift has only one major version line, 4.

Resources

• tbd

  Responsibilities

• OTA team for CVO enablement
• API server team for compatibility statements

Success criteria

• OSUS / Cincinnati graph data include OCP 4 and 5 minor releases in the appropriate channels
• Kube API server operator correctly calculates the next Kubernetes version for OCP 5.x releases
• Customers can trigger an update from OCP 4.22 to OCP 5 via CVO
• Deprecation statements in APIs (ex: DeploymentConfig) are updated to include OCP 5