1. Proposed title of this feature request

Providing RHCOS containerdisk images for OpenShift Virtualization and Hypershift [1].

2. What is the nature and description of the request?

ContainerDisks are a canonical way in OpenShift Virtualization (CNV) and KubeVirt to ship root images for various use-cases
from a container registry. Quite recently RHEL started shipping containerdisks in addition to their usual distribution paths specifically for OpenShift Virtualization [2].
Being able to ship RHCOS in a similar way to customers aligns the delivery strategy of RHCOS for CNV and Hypershift.

What we want to achieve is basically shipping the releases in [5] as containerdisks from a well-known registry where we can discover the right rhcos image for a given ocp-release payload from within hypershift.

Taking some brainstorming ideas from slack [6] to illustrate this: It would for instance be great to ship always when RHCOS is pushed to [5] in addition a new containerdisk with corresponding tags which would live alongside quay.io/openshift-release-dev/ocp-release and/or in registry.redhat.io.

Since this came up fast in the slack conversation: We don't need the image to be part of the payload. Shipping it in parallel (similar to AWS AMIs for rhcos) as containerdisk is what we would need. It is also important to mention, that for testing we would prefer to have the images public available too, like it is the case for the payload in openshift-release-dev on quay.

To better illustrate what a continerdisk is, here an example how a person can right now build its own containerdisk for RHCOS (and [7] shows it for rhel):

FROM scratch
ADD --chown=107:107 https://mirror.openshift.com/pub/openshift-v4/dependencies/rhcos/4.9/4.9.0/rhcos-openstack.x86_64.qcow2 /disk/

Then people can just reference it on their VirtualMachines in CNV.

Initially we only require x86_64. At some point arm will probably be interesting too for us (upstream of CNV and possible upcoming edge needs for OpenShift indicate that).

release-payload changes:

Finally, similar to the AWS release payload, we want to be able to read out the RHCOS release for the kubevirt platform too. So if the release payload is read, the json file in there should point to our registry with the correct RHCOS tag.

3. Why does the customer need this? (List the business requirements here)

Benefits for the customer in the context of the HyperShift use-case:

• A canonical way for customers on how to receive root disks maintained by Red Hat which fits perfect into OpenShift
• mirroring for airgapped installations
• Making images for VMs with the same access control mechanisms available like any other container content
• Works nice with the cluster api provider for kubevirt in hypershift [3][4].

4. List any affected packages or components.

• ART
• CoreOS/RHCOS

[1] https://issues.redhat.com/browse/CNV-11945
[2] https://issues.redhat.com/browse/RHELBU-905
[3] https://github.com/kubernetes-sigs/cluster-api-provider-kubevirt
[4] https://github.com/openshift/hypershift/pull/779
[5] https://mirror.openshift.com/pub/openshift-v4/dependencies/rhcos/
[6] https://coreos.slack.com/archives/C999USB0D/p1639493449172400
[7] https://catalog.redhat.com/software/containers/rhel8/rhel-guest-image/601d79b5cc1405c84e0d24a4?container-tabs=dockerfile