Add metal platform provider

[rccrdpccl]

Feature Request

Use case:
Installing OpenShift via CAPI, on baremetal. The infrastructure provider used is CAPM3.

When installing OpenShift through CAPI, the infrastructure provider shares per-host metadata through a configdrive. With cloud-init, this can be read and everything works as expected, however it's seems not to be so straightforward with ignition, at least in the case of metal platform (CAPM3).
Without this metadata, the bootstrap/controlplane providers are forced to couple with infrastructure providers to extract the data in-cluster, which is far from ideal from a CAPI architecture perspective.

If we could add metal platform, we could add expected metadata from CAPM3 (metal3-namespace, metal3-name, etc), or possibly dynamically adding all keys in the metadata file.

As part of a CAPI bootstrap/controlplane provider, som

Environment

What hardware/cloud provider/hypervisor is being used to run Afterburn?

Baremetal, ironic is in charge of creating and sharing the needed config drive.

Desired Feature

Metal platform provider. Loading metadata from configdrive attributes into env vars as other providers:

AFTERBURN_METAL_UUID
AFTERBURN_METAL_METAL3_NAMESPACE
AFTERBURN_METAL_METAL3_NAME
AFTERBURN_METAL_LOCAL_HOSTNAME
AFTERBURN_METAL_NAME

Other Information

Currently the proposed workaround is to adapt openstack provider. However out of the metadata attributes that need to be used (METAL3_NAMESPACE, METAL3_NAME , AFTERBURN_METAL_UUID) we'd only have UUID available.

[rccrdpccl]

cc @jlebon

[rccrdpccl]

current workaround PR: #1131

[jlebon]

I think we can come up with something to address your needs.

First though, I'd say we shouldn't add a new provider called metal. At the CoreOS level, "metal" more or less means you own the infrastructure piece and you're not running on any platform in particular. E.g. could be an actual bare metal machine or in QEMU. So there isn't really any well-known metadata keys to expect and expose to users. Similarly, the metal platform in Ignition has no provider code. It's assumed that you're feeding the Ignition config through some of the other supported means.

One approach is to add a e.g. metal3 provider, but I think probably the simplest approach is to extend the openstack provider to detect and pass through the Metal3 keys it finds in meta_data.json. The argument for the latter is that Metal3 in using OpenStack tech is essentially trying to conform to OpenStack APIs and so e.g. it would be expected to keep using the OpenStack image, platform ID, and any code conditionalized on that.

Where this gets awkward is if more things come along later that also claim to support the OpenStack API but want their own keys passed through as well. If that happens, we can revisit how this is implemented to make it more flexible.

[rccrdpccl]

Metal3 wouldn't necessarily be using openstack image, but in any case I think we can work with that: by running afterburn with platform openstack we can still inject the necessary metadata.

In any case, it makes sense extending openstack provider instead.

I will follow up with a PR adding the relvant keys to the openstack metadata.

[jlebon]

Metal3 wouldn't necessarily be using openstack image, but in any case I think we can work with that: by running afterburn with platform openstack we can still inject the necessary metadata.

Sorry, can we dig into that? To confirm, you're currently using the OpenStack image, right? Do you need to also support e.g. booting the live ISO and running coreos-installer?

[rccrdpccl]

In the CAPI provider that we are working on, we are targeting baremetal platform to start with, but soon we will target also OpenStack. And if the approach would work for any platform, even better
Currently the flow works this way:

• the user sets an image to boot the host, through metal3 machine template.
• CAPI Bootstrap controller will retrieve ignition from assisted installer, and will set it as userdata for the previously set image, which will be booted by Metal3 system
• Ignition will basically install the new system in a new ostree state root, and we'll boot into that once we reboot

LiveISO flow is separate for now, and with the userdata/ignition only flow coreos installer won't be used. This means we wouldn't be using afterburn in this way with LiveISO (@carbonin please keep me honest here)

The user is technically free to set whatever image they want, however we can recommend what to choose (i.e. an image https://mirror.openshift.com/pub/openshift-v4/dependencies/rhcos/4.17/).
I would expect the user to choose an image that would fit their platform.