gf-oemid: Support replacing oemid

[cgwalters]

Today we only build a qemu image. I plan to work on
"build postprocessing" tools so that one can take an existing
build and extend it with more image types.

This is prep for that, by allowing us to replace the qemu image's
oemid.

[jlebon]

I plan to work on
"build postprocessing" tools so that one can take an existing
build and extend it with more image types.

How does this relate to the buildcfg.yaml idea in #80? Because I really like that it strongly connects them all as one "compose" vs. doing it as a secondary step.

[cgwalters]

How does this relate to the buildcfg.yaml idea in #80? Because I really like that it strongly connects them all as one "compose" vs. doing it as a secondary step.

Right. So...I would like to do "progressive builds" - like where we first build the ostree, and possibly rebase an existing system to it to test. And/or we then next build the qemu.qcow2, and in the same build container boot it and run basic sanity checks.

I don't want to upload AMIs to every region on every build, or build an installer ISO if the basic boot in qemu test fails.

This also relates to an idea I had around adding a "tags" toplevel element to the builds.json, so that one could promote a tested build: e.g. extend it to all AWS regions, then create tag.

[cgwalters]

The other thing is that #80 implies a new config file which all the tools would need to parse, and that quickly gets into the language issue. I feel like we still should do #80 in terms of at least defining a "baseline" - people interested in bare metal systems may never want a -qemu.qcow2 etc.

[lucab]

It could be that I'm just echoing the comments above in a different form, but I'm wary of trying to replace/reuse bits across images/OEMs. In CL we have an intermediate neutral GPT-disk image (coreos_production_image.bin) that is used internally in the SDK as the pristine baseline image to produce all other OEM images.

[cgwalters]

In CL we have an intermediate neutral GPT-disk image

Right, there's also a pristine image in c-a. But in the end right now the only thing different between our images is the oem.id. If we were to do something like the OEM partition then clearly this would need to change. But since we're not doing that now...

[jlebon]

I don't want to upload AMIs to every region on every build, or build an installer ISO if the basic boot in qemu test fails.

That makes sense to me, though we could just make that part of the build process. I.e. after building the qcow2, sanity check it boots, and then continue on to do the derivatives. Though I admit it's a bit odd to have build be that smart.

Anyway, this patch looks sensible enough on its own merits.

[dustymabe]

👍