Uploaded image for project: 'OpenShift Container Platform (OCP) Strategy'
  1. OpenShift Container Platform (OCP) Strategy
  2. OCPSTRAT-1150

[Dual stream] Support two major versions of RHEL CoreOS in a single OCP release & cluster

XMLWordPrintable

    • Strategic Product Work
    • False
    • Hide

      None

      Show
      None
    • False
    • OCPSTRAT-1450Converge RHEL CoreOS with Image mode
    • 100% To Do, 0% In Progress, 0% Done
    • 0

      Feature Overview (aka. Goal Summary)  

      OpenShift 4 introduced an opinionated, appliance-like approach to Kubernetes worker nodes. The cluster took away almost all of the maintenance and management aspects of running clustered RHEL CoreOS compute nodes for OCP. That includes selecting the minor version of RHEL being shipped and enforcing that version across all cluster nodes.

      However, there is a strong case for allowing two different major versions of RHEL in a single minor version of OCP.

      For example:

      • Some OEMs do not certify older server models on new RHEL major versions during the production life span of the server. This can cause hardware support issues
      • It gives customers more time to get RHEL 10 bits internally certified
      • It allows a longer migration path for new drivers & other kernel modules

      Goals (aka. expected user outcomes)

      For example, if we do this for the introduction of RHEL 10, it would mean:

      • Clusters can be installed with 9.8 or 10.2 as the base image
      • Clusters can have varying versions of RHCOS in different machineconfigpools of the same cluster
      • Red Hat continues to decide which RHEL minors can be used with RHCOS

       

      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 We will need to think through the installer flows here.
      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)  

      Use Cases (Optional):

      Questions to Answer (Optional):

      Out of Scope

      This feature does not contemplate allowing "any supported version of RHEL" or using RHEL minors that are not EUS releases.

      Customer Considerations

      Documentation Considerations

      Interoperability Considerations

      Having 9 and 10 available in one release will increase testing scope.

              rhn-support-mrussell Mark Russell
              rhn-support-mrussell Mark Russell
              Derrick Ornelas Derrick Ornelas
              Votes:
              0 Vote for this issue
              Watchers:
              31 Start watching this issue

                Created:
                Updated: