Deploying OCP-4.21 on a RHCOS 10 system

Nacho Silla

6 minutes read

Back to all posts

Introduction

The upcoming OCP release 5 is announced to run on RHCOS/RHEL version 10.

As this Openshift Container Platform (OCP) version approaches its release date, OCP releases 4.20 and 4.21 are announced to provide dual support for Red Hat Enterprise Linux CoreOS (RHCOS) 9 and 10 versions.

However, the different installation methods don't provide an explicit option to enable the deployment of the cluster on an operating system version different than the default one.

While previous OCP versions offered the parameter "clusterOSImage" in the install-config.yaml file definition, newer releases seem to have deprecated this option in favor of a machine configuration specifying the OS image by means of specific OpenShift release payload images, as shown in the following example:

apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
  labels:
    machineconfiguration.openshift.io/role: master
  name: 99-override-rhel10
spec:
  osImageURL: quay.io/openshift-release-dev/ocp-v4.0-art-dev@sha256:0d41fa7433b6f5dc81a1260352426e546a14c4252a57da8d673d08e294959158

This configuration may then be provided to the installer in order to have the target OS version installed at Day 0.

It's worth mentioning this method only allows using a RHEL 10 based image as the installed OS version in the final cluster. When deploying the OCP 4.20 and 4.21 versions, the RHCOS version of the discovery ISO will remain at 9.x.

Procedure

Note the actions described in this article are valid for both, OCP 4.20 and 4.21. In this article we'll focus on 4.21, but the described procedure will work as well on 4.20.

Likewise, although in this document we'll focus on the Agent Based Installer (ABI) deployment method, other methods like Installer-Provisioned Infrastructure (IPI) can be used adapting the steps as required.

In order to deploy an OCP release earlier than 5 on a RHCOS 10 cluster, the first step is identifying the URL of the OCP release payload image associated to the target release version.

By the time of writing this article, the latest OCP 4.21 version available was 4.21.17.

We can get the appropriate image URL using the ocp adm sub-command:

$ oc adm release info --image-for=rhel-coreos-10 quay.io/openshift-release-dev/ocp-release:4.21.17-x86_64
quay.io/openshift-release-dev/ocp-v4.0-art-dev@sha256:0d41fa7433b6f5dc81a1260352426e546a14c4252a57da8d673d08e294959158

The resulting URL is the value to be set in the machine configuration manifest described above.

The manual way

In order to run this deployment manually, we need to embed the machine configuration manifest in the discovery ISO image.

In order to do so, after creating the install-config.yaml file, we must create the sub-directory /manifests in the same folder containing the install-config.yaml and place the machine configuration manifest there:

$ ls deployment
install-config.yaml

$ mkdir deployment/manifests

$ cat << EOF > deployment/manifests/99-override-rhel10.yaml
apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
  labels:
    machineconfiguration.openshift.io/role: master
  name: 99-override-rhel10
spec:
  osImageURL: quay.io/openshift-release-dev/ocp-v4.0-art-dev@sha256:0d41fa7433b6f5dc81a1260352426e546a14c4252a57da8d673d08e294959158
EOF

Then we may create the discovery ISO image on this directory:

openshift-install agent create image --dir ./deployment

From this point on, it's a matter of following the standard deployment procedure that will result in the cluster deployed on the target RHCOS version:

$ oc get clusterversion,node; oc get nodes sno1 -o custom-columns=OS:.status.nodeInfo.osImage                  
NAME                                         VERSION                              AVAILABLE   PROGRESSING   SINCE   STATUS                            
clusterversion.config.openshift.io/version   4.21.0-0.nightly-2026-05-27-093820   True        False         44m     Cluster version is 4.21.0-0.nightl
y-2026-05-27-093820                                                                                                                                   

NAME                               STATUS   ROLES                         AGE   VERSION                                                               
node/sno1   Ready    control-plane,master,worker   75m   v1.34.8                                                               
OS                                                                                                                                                    
Red Hat Enterprise Linux CoreOS 10.2.20260513-0 (Coughlan)

The DCI way

As usual, it's possible to automate this deployment procedure using the DCI tools.

The process to do so requires identifying the release payload image URL and creating the machine configuration manifest as explained before.

After doing so, it's a matter of setting the proper DCI variables in an inventory or pipeline file.

For the purpose of this article, let's say we have a DCI pipeline manifest named "abi" (abi-pipeline.yaml):

- name: abi
  stage: openshift
  topic: OCP-4.21
# THE FILE CONTINUES...

We plan to run it on a DCI queue named "sno". The usual way to schedule the pipeline would be:

$ dci-pipeline-schedule -p sno abi

To test this procedure, we could instruct the installer to use our machine configuration manifest by setting the extra_manifests variable:

$ dci-pipeline-schedule -p sno abi 'abi:ansible_extravars={"extra_manifests":[{"file":"/path/to/machine_config.yaml"}]}'

Where:

In this case, given the complex structure of the object, ansible_extravars is set as a json object, so there are a few precautions we have to take:

With this, you'll see the DCI job processes and uses the manifest:

TASK [Add performance profile to extra manifests in ABI] ***********************
task path: /usr/share/dci-openshift-agent/plays/abi-install.yml:149
Thursday 28 May 2026  13:01:13 +0000 (0:00:00.425)       0:04:24.291 ********** 
ok: [jumphost] => {"ansible_facts": {"dci_extra_manifests": [{"file": "/path/to/machine_config.yaml"}, {"file": "/home/dci/dci/ci-config/files/performance-profile/blueprint-worker-baremetal.yml"}]}, "changed": false}

Finally, for a persistent setup, we may add the path to the manifest to the pipeline definition file itself:

- name: abi
  stage: openshift
  topic: OCP-4.21
  ansible_extravars:
    extra_manifests:
      - file: /path/to/machine_config.yaml
# THE FILE CONTINUES...

Which we can schedule as usual:

$ dci-pipeline-schedule -p sno abi

Conclusion

The procedure described in this article enables us to leverage the OCP 4.20 and 4.21 capabilities to dual boot on RHCOS/RHEL 9 and 10.

This gives us a good opportunity to test in advance the OCP integration with RHCOS 10 and, with the help of DCI, we may do so with all the advantages of a fully operative Continuous Integration (CI) solution.

Nacho Silla