buildextend: create initramfs and kernel artifacts

[mike-nguyen]

The installer ISO generation already pulls the initramfs and kernel
from the ostree repo so this just piggybacks off that and copies the
artifacts to the build directory. Having the initramfs and kernel is
useful for tools like virt-install and OZ to look at a tree and boot
the kernel with fine grain control over the kernel command line.

[miabbott]

LGTM

[cgwalters]

Having the initramfs and kernel is
useful for tools like virt-install and OZ to look at a tree and boot
the kernel with fine grain control over the kernel command line.

But those projects currently only know how to parse traditional Pungi/lorax/Anaconda generated .treeinfo/"install tree" directories, right?

IOW you can't just virt-install --location https://ci.centos.org/artifacts/fedora-coreos/prod/builds/29.841/ even after this lands. Which is fine! But are we trying to scope that in?

It feels like this is more about "convenience of retrieving" the kernel/initrd. They're in that ISO (and for that matter the qemu/etc images)...but extracting them from the .iso requires tooling not everyone will have handy.

I'm fine with this patch as is, but I wonder whether it'd be better to e.g. tar up the kernel/initramfs together. Everyone will have tar - this way it's only one HTTP fetch.

Also...today we add the version number into our VM images - I think we should do the same with this, so that one can drop multiple builds into a PXE server and not have them conflict.

[mike-nguyen]

Having the initramfs and kernel is
useful for tools like virt-install and OZ to look at a tree and boot
the kernel with fine grain control over the kernel command line.

But those projects currently only know how to parse traditional Pungi/lorax/Anaconda generated .treeinfo/"install tree" directories, right?

IOW you can't just virt-install --location https://ci.centos.org/artifacts/fedora-coreos/prod/builds/29.841/ even after this lands. Which is fine! But are we trying to scope that in?

It feels like this is more about "convenience of retrieving" the kernel/initrd. They're in that ISO...but extracting them from the .iso requires tooling not everyone will have handy.

I copied some of the commit message from the upstream issue: coreos/fedora-coreos-tracker#161. @imcleod can you clarify on how you use these artifacts?

I'm fine with this patch as is, but I wonder whether it'd be better to e.g. tar up the kernel/initramfs together. Everyone will have tar - this way it's only one HTTP fetch.

Also...today we add the version number into our VM images - I think we should do the same with this, so that one can drop multiple builds into a PXE server and not have them conflict.

taring the file makes sense. The files won't need to be renamed and the tar filename can be versioned.

[arithx]

One benefit to producing these individually rather than in a tar is that in iPXE setups they can reference the upstream / production buckets rather than downloading and re-hosting.

[cgwalters]

The files won't need to be renamed and the tar filename can be versioned.

Yep, I'm also suggesting adding the version to the kernel/initramfs so that one can safely unpack the tarball into a PXE server directory and not overwrite earlier builds.

[mike-nguyen]

We have a use case to keep them uncompressed and separated for iPXE. I'll just do the rename with the version and keep them separated unless there are objections.

[cgwalters]

The iPXE argument makes sense, so SGTM!

[mike-nguyen]

⬆️ pushed changes for

• rename file with version
• skip compression of the initramfs and kernel