XMLWordPrintable

    • Product / Portfolio Work
    • OCPSTRAT-1112OpenShift Update Channel Changes- Single channel, EUS, PWPU
    • 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)  

       

       

              rh-ee-smodeel Subin M
              rh-ee-smodeel Subin M
              None
              Daniel Messer, Steve Gordon
              Scott Dodson Scott Dodson
              Pratik Mahajan Pratik Mahajan
              Jianwei Hou Jianwei Hou
              Avani Bhatt Avani Bhatt
              Eric Rich Eric Rich
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

                Created:
                Updated: