Add 'metal' oem id

[dustymabe]

Feature Request

Environment

Fedora CoreOS bare metal hardware.

Desired Feature

Add support for 'metal' OEM ID. See coreos/fedora-coreos-tracker#142 and coreos/coreos-assembler#339 for context. I'm not sure exactly what functionality we should bake in since bare metal is essentially a non-platform, but we can discuss here I guess.

[lucab]

Additionally, I think there are two orthogonal sub-topics contained in this:

• which logic would metal.FetchConfig implement? That is, where does 'metal' get its configuration by default?
• should the oem-lookup logic have a default case wired to noop.FetchConfig for future-proofing the introduction of new platforms?

[ajeddeloh]

Looks like right now on CL for bare metal just doesn't have it set at all (someone correct me if I'm missing something).

which logic would metal.FetchConfig implement? That is, where does 'metal' get its configuration by default?

noop.FetchConfig. Kernel command line args and the embedded config are the standard ways to pass in the config on bare metal unless you have a novel idea

should the oem-lookup logic have a default case wired to noop.FetchConfig for future-proofing the introduction of new platforms?

To clarify, this is asking "If Ignition encounters an oem-id it doesn't know about, should it default to noop.FetchConfig?" I'd be ok with this (probably log something too). The only difference between this and the metal oem would be logging the "I don't know this oem" message, right?

[cgwalters]

I think it was Benjamin who raised the idea of /boot/config.ign[.gz] - that'd be convenient in non-PXE cases and would replace the OEM partition. See coreos/ignition-dracut#42

[ajeddeloh]

@cgwalters are you referring to having the logic to mount /boot and read from /boot/ignition/config.ign[.gz] baked into Ignition for the metal provider (Ignition internally refers to them as "providers")? Would we still want to do that on other platforms. I'm not sure if our current behavior is useful for anything but bare metal; on any cloud it wouldn't get used unless someone is baking custom images.

[lucab]

@ajeddeloh your followups are correct.

I think we are looking for some new logic for the metal provider, and that isn't the noop provider. Possibly a replacement for the oem provider, but fitting into the new partition scheme.

And the default "log+noop" case on unknown oem-id would allow to experiment with new platforms without having to patch Ignition first.

[bgilbert]

I'm in favor of using noop and letting distro scripts continue to find config.ign and copy it into the initramfs. The config.ign path and needed devices/mounts may vary across distros. Also, that file is also likely to be used on non-metal platforms. For example, CL users routinely run coreos-install on VMware.

I'm also in favor of continuing to fail on an unrecognized platform ID. In that case we know there's something wrong, e.g. a typo, that could cause an intended network fetch to be skipped. And of course we've generally tried to hard-fail when errors are detected. IMO new platforms aren't added often enough for the convenience to be worth the risk.

[ajeddeloh]

@bgilbert do you see value Ignition looking for config.ign in the initramfs when the platform id is not metal?

[bgilbert]

Yeah, people PXE-install VMs, and the installer will still need to write the Ignition config.

[ajeddeloh]

Sounds like we're settled on adding a metal oem that just does noop. PR here: #732

[dustymabe]

fixed in #732
should we close this out?