No RHCOS image in baremetal Machines and MachineSets

[markmc]

From openshift-metal3/kni-installer#160

In the Generate() function for masters and workers under pkgs/assets/machines every other platform except libvirt generates an RHCOS image asset and includes it in the Machines or MachineSets it generates

Why isn't the baremetal platform doing this?

(NB - currently on baremetal the generated RHCOS image is the qcow image we use with libvirt for the bootstrap VM. If we were to include bootimage info in the generated machine manifests, we would need to make it have the proper URL instead)

Some of the underlying assumptions of the rhcos.Image abstraction:

The same image is used for bootstrap, masters, and workers
That image information is included in the generated machines manifests and also to terraform
I think we should follow that basic idea and just have an "oh hey, our bootstrap node boot image is different!" special case

[markmc]

/label platform/baremetal

[hardys]

This is also related to openshift-metal3/kni-installer#58 - I think ideally we want to remove the image parameter completely from the install-config, since when the Ironic provisioning of masters and workers happen, the URL needed is different in each case.

That's really an internal implementation detail, and when we've got Ironic hosted on the bootstrap VM via openshift-metal3/kni-installer#100 we'll know where the images will be as an internal implementation detail, e.g we can set the terraform variables for instance/driverInfo based on knowledge of the provisioning IP of the bootstrap VM.

So the remaining missing piece is to set the providerSpec for the machineset, which currently gets set to the same install-config image data, which is wrong in the case where it points to the bootstrap VM, and there's no way to differentiate between master/worker images at that level.

[hardys]

Looking at this rhcos.Image is currently a string, and it's consumed like:

    machines, err = aws.Machines(clusterID.InfraID, ic, pool, string(*rhcosImage), "master", "master-user-data")

So I wonder if we can insteadm make Image a struct (renamed to Images?) then have two keys, bootstrapImage and osImage?

Then for all platforms where these are the same, they'd return the same value.

[hardys]

Another possbly less invasive approach would be to add a new abstraction e.g rhcos.OSImage which returns rhcos.Image for all platforms except those where the bootstrap and OS images don't match?

I need to resolve this for bootstrap hosted Ironic ref #2035 so perhaps @abhinavdahiya may be able to provide some feedback on the preferred approach and I'll work on a PR, then rebase #2035 to align with the new interface and enable templating of the OSImage?

Then we can decouple the bootstrap download of that image from the providerSpec for the workers (which will use a cached copy of the same file).

One question is how do we handle updating of this image on upgrade, e.g when the cluster upgrades to a new version, will the machineset providerSpec get updated, and if so how?

[hardys]

One question is how do we handle updating of this image on upgrade, e.g when the cluster upgrades to a new version, will the machineset providerSpec get updated, and if so how?

Discussion indicates that currently no platforms support changing the boot image post deploy, and rely on the upgrade of the bootimage after provisioning. So that simplifies things a bit.

[cgwalters]

Discussion indicates that currently no platforms support changing the boot image post deploy,

openshift/os#381

[hardys]

Discussion indicates that currently no platforms support changing the boot image post deploy,

openshift/os#381

Ack thanks - the issue for Baremetal IPI right now is that we download/cache the bootimage at the time of initial deployment. As support for updating the bootimage evolves we can certainly figure out how to refresh that, but it seems that we can defer that work until the initial integration is completed.

[hardys]

/assign

[juliakreger]

@dhellmann FYI