Uploaded image for project: 'OpenShift Bugs'
  1. OpenShift Bugs
  2. OCPBUGS-54611

Machine-config operator should drop redundant kubelet-skew guard

XMLWordPrintable

    • Quality / Stability / Reliability
    • False
    • Hide

      None

      Show
      None
    • None
    • None
    • None
    • None
    • None
    • Done
    • Bug Fix
    • Hide
      * Previously, users were not warned if their cluster contained RHEL worker nodes, which are no longer supported in {product-title} 4.19 and later. With this release, the Machine Config Operator now detects bare-RHEL Nodes and warns users that they will not be compatible with {product-title} 4.19. (link:https://issues.redhat.com/browse/OCPBUGS-54611[OCPBUGS-54611])
      Show
      * Previously, users were not warned if their cluster contained RHEL worker nodes, which are no longer supported in {product-title} 4.19 and later. With this release, the Machine Config Operator now detects bare-RHEL Nodes and warns users that they will not be compatible with {product-title} 4.19. (link: https://issues.redhat.com/browse/OCPBUGS-54611 [ OCPBUGS-54611 ])
    • None
    • None
    • None
    • None

      Based on the coming official announcement in https://issues.redhat.com/browse/OCPSTRAT-1865, the support for RHEL worker nodes will be removed in OCP 4.19. Consequently, for existing OCP clusters (version 4.18 or earlier) with RHEL worker nodes, it has become technically infeasible to perform a complete cluster upgrade (including RHEL workers) to version 4.19.

      Theoretically, in such scenarios, prior to upgrading the cluster to 4.19, users should:

      1. Migrate workloads from RHEL worker nodes to RHCOS nodes
      2. Remove all RHEL worker nodes from the cluster
      3. Start the OCP cluster upgrade

       

      Therefore, we strongly recommend that the CVO implement an upgradeable condition check that would:

      • Automatically block cluster upgrade to 4.19 by default when RHEL worker nodes are detected
      • Require administrative confirmation to continue the cluster upgrade

       

      I'm not sure about the feasibility of implementing this functionality and whether it aligns with the OTA team's technical roadmap. Any feedback or suggestions would be highly appreciated.

      Thanks.

              trking W. Trevor King
              rh-ee-gpei Gaoyun Pei
              None
              None
              Gaoyun Pei Gaoyun Pei
              None
              Votes:
              0 Vote for this issue
              Watchers:
              5 Start watching this issue

                Created:
                Updated:
                Resolved: