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.6 or 10.0 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.

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.