-
Feature
-
Resolution: Unresolved
-
Major
-
None
-
None
-
Product / Portfolio Work
-
-
False
-
None
-
False
-
L
-
None
-
None
-
None
-
None
-
-
None
-
None
-
None
-
None
-
Undefined
Feature Overview
Support y-version rollbacks in OCP by Integrating Kubernetes' compatibility versioning (KEP-4330) into OpenShift's upgrade process . Provide a safe, time-limited rollback window for minor version (e.g., 4.N to 4.N+1) control-plane upgrades,
Goals (aka. expected user outcomes)
The cluster administrator persona will be able to perform an OpenShift minor version upgrade with a defined, automated two-step process that temporarily locks the cluster to the old API/feature set after installing the new binaries. This process will:
- Provide a reliable, safe path for immediately rolling back the control plane to the previous version if critical issues are detected during the validation period.
Requirements (aka. Acceptance Criteria):
- The OpenShift Kubernetes API Server (KAS) must adopt and support the --emulation-version flag.
- The Cluster Version Operator (CVO) must implement a mandatory two-step upgrade sequence for minor versions that utilizes the emulation mode.
- In the first step (validation period), the new KAS binaries are installed, but the --emulation-version is explicitly locked to the previous version's behavior.
- A documented and supported method for initiating a control-plane rollback must be available during the validation period.
- The second step (finalization) must promote the emulation version to the new binary version, making the rollback path irreversible after this point.
- The CVO policy must strictly prevent the cluster from remaining in a long-term emulated state (Binary N running Emulation N-X) in a production environment.
Out of Scope
- Exposing "emulation modes" as a permanent production feature for customers to manage.
- Rollback support for OpenShift layered components or OLM content in Phase 1.
- Rollback after the upgrade finalization step.
Anyone reviewing this Feature needs to know which deployment configurations that the Feature will apply to (or not) once it's been completed. Describe specific needs (or indicate N/A) for each of the following deployment scenarios. For specific configurations that are out-of-scope for a given release, ensure you provide the OCPSTRAT (for the future to be supported configuration) as well.
| Deployment considerations | List applicable specific needs (N/A = not applicable) |
| Self-managed, managed, or both | |
| Classic (standalone cluster) | |
| Hosted control planes | |
| Multi node, Compact (three node), or Single node (SNO), or all | |
| Connected / Restricted Network | |
| Architectures, e.g. x86_x64, ARM (aarch64), IBM Power (ppc64le), and IBM Z (s390x) | |
| Operator compatibility | |
| Backport needed (list applicable versions) | |
| UI need (e.g. OpenShift Console, dynamic plugin, OCM) | |
| Other (please specify) |
- clones
-
OCPSTRAT-1587 Expand Control Plane Only Updates to 4.N to 4.N+2 and 4.N+3 independent of EUS versions
-
- Refinement
-
- is cloned by
-
OCPSTRAT-2638 OpenShift Skip-Level Update
-
- New
-