Consider dropping deploy kernel/ramdisk from install config

[russellb]

The install config currently includes options like:

          deploy_kernel:  "http://172.22.0.1/images/ironic-python-agent.kernel"
          deploy_ramdisk: "http://172.22.0.1/images/ironic-python-agent.initramfs"

We should aim for Ironic to be an implementation detail, and this leaks a bit of info. We also don't expect this image to ever change. Since we know exactly what image should be used, the installer should automatically download it and ensure it's available via HTTP from somewhere.

[stbenjam]

Should the installer do it? Or could we have the Ironic container take care of it? If the installer needs to do it, where do we host it? We'd have to have it available from somewhere in the bootstrap environment, and also later in the running cluster.

[russellb]

Yeah, that's a good idea. Maybe we could include it in our ironic container?

I'm not tied to any particular solution. I just think making this not a concern of the install-config should be a todo item.

[dhellmann]

When we talked about this in the context of packaging the operator and actuator, we tossed around the idea of having the operator provide a web server container with these things and the actuator providing a web server containing the images to be deployed. @imain was looking at that.

[russellb]

That works for day 2, but not the day 1 installer when the operator and actuator aren't running yet.

[dhellmann]

Good point. We also talked about that container just being a cache, so maybe we can use the same container image in both cases?

[hardys]

I think with the new downloader containers, and the work to move those and the ironic services to the bootstrap VM, we can make progress on this soon.

Ref #100 - the IP of the bootstrap VM will be known (either hardcoded or available via a survey input), so we will know where the ramdisk/kernel and RHCOS image should be when deploying via terraform (the same approach can be used on cluster too, but the URL will obviously be different).

One question is what do we put in the baremetal host definition for the masters, when the URL for the images goes away as soon as bootstrap is completed?

[dhellmann]

One question is what do we put in the baremetal host definition for the masters, when the URL for the images goes away as soon as bootstrap is completed?

The master hosts will be registered with a machine reference but no image information. That will make them appear as "externally provisioned" and prevent the operator from trying to re-provision them when it is launched inside the cluster.

[hardys]

One question is what do we put in the baremetal host definition for the masters, when the URL for the images goes away as soon as bootstrap is completed?

The master hosts will be registered with a machine reference but no image information. That will make them appear as "externally provisioned" and prevent the operator from trying to re-provision them when it is launched inside the cluster.

Ah thanks, I'd forgotten the externally provisioned status omitted the image details. Sounds like we can just remove this from the install-config when the images are hosted on the bootstrap VM then.

[russellb]

@hardys It looks like the change to make Ironic run on the bootstrap VM will remove the need for these install-config options. Can you confirm? Do you want to include dropping these options in your PR, or should I file an openshift/installer issue to remind us to follow up on it?

[hardys]

@hardys It looks like the change to make Ironic run on the bootstrap VM will remove the need for these install-config options. Can you confirm? Do you want to include dropping these options in your PR, or should I file an openshift/installer issue to remind us to follow up on it?

Yes my plan is to drop all image install-config options through a combination of openshift/installer#2037 to decouple the images internally, then the boostrap-ironic change which will mean we know where the images will reside in the master deployment case.

I think we do need to copy #68 to openshift/installer though?

[hardys]

openshift/installer#2060 raised to move tracking of #68 to openshift/install