Platform ID for bare-metal images (raw GPT disk)

[lucab]

#91 is tracking progress on a bare-metal installer, based on dd-ing a raw GPT image to disk.

As prerequisite for that, coreos-assembler pipeline has to start producing such a raw GPT disk image. Currently, CL has coreos_production_image.bin.bz2 which is mostly equivalent to this and consumed by coreos-install.

Before doing that, we should allocate a platform ID so that we are not losing static information when moving from buildtime to runtime. Software on those nodes can introspect that ID to detect the environment they are in and apply conditional logic (e.g. Ignition config fetcher).

I think there may be a few factors that may affect the granularity of this bare-metal ID, such as:

• Boot method (BIOS, UEFI or a dual-image for both)
• Measured boot (on UEFI with TPM, whether the node is performing boot measurement/attestation)
• Multiple kinds of images (will we need to produce and distinguish different geometries in the future?)

[bgilbert]

I agree that we should have a distinct platform ID for bare metal.

BIOS/UEFI, measured boot on/off, and 512b/4Kn disks all strike me as options within a platform, rather than fundamentally different platforms. By analogy, AWS images may run on multiple virtualization types (HVM vs. PV) and multiple hypervisors, but CL has only one OEM ID for them.

[cgwalters]

PR in coreos/coreos-assembler#339

[dustymabe]

issue against ignition to add this: coreos/ignition#724

[dustymabe]

a 'metal' platform id was added to ignition in coreos/ignition#732 - It will filter down into FCOS in the next ignition release. Closing this out for now.