extensible metadata on deployments

[cgwalters]

As prep for #2725 but also in general, I think it'd be useful to have an official "metadata" API for deployments - surfacing things like "did this deployment boot before" in a way indepdenent of the journal.

I think this could be a pretty thin wrapper for extended attributes on the deployment root directory. (Need to verify whether the immutable bit breaks this; if it does we could just document using the origin file for this)

[cgwalters]

BTW if we do this we should also teach the OpenShift MCO to do this, to describe which rendered configs it used for the deployment.

[cgwalters]

One thought related to this is that with composefs, we automatically gain a new .cfs file that would a natural target for xattrs.

[cgwalters]

(And maybe we should just turn on composefs generation unconditionally by default?)

[jmarrero]

we discussed turning composefs for Fedora ELN first.

[cgwalters]

One thing that happened with #3114 is we gained a whole new directory created unconditionally now - so we can trivially drop in a new file there in whatever format we want (but probably gvariant) or xattrs on that directory.

[cgwalters]

This one also tangentially relates to https://systemd.io/AUTOMATIC_BOOT_ASSESSMENT/ as the success/failure of a boot is something that could make sense here - or in the bootloader configs.

[jmarrero]

I see that is targeted for kernel-install to start the process. Since we are not doing a kernel install but a deployment, we could:

• check what kernel is part of the deployment
• ostree exposes a boot_retry count option
• ostree creates: /etc/kernel/tries with the boot_retry value.
• ostree creates: /boot/loader/entries/KERNEL_VER.fc27.x86_64+BOOT_RETRY.conf

Then the process described in the Walkthrough section of https://systemd.io/AUTOMATIC_BOOT_ASSESSMENT/ will take over. We can embed additional information on /boot/loader/entries/KERNEL_VER.fc27.x86_64+BOOT_RETRY.conf for greenboot to consume either in the file itself as text as long systemd does not care or extended attributes if systemd cares about file content.

[cgwalters]

xref https://github.com/systemd/systemd/blob/0630069f0bdba4535c2c659fbf2c9aa632268272/src/kernel-install/90-loaderentry.install.in#L96 and coreos/rpm-ostree#4726

[cgwalters]

I think for this the source of truth is the bootloader entry, same with ostree.

ostree exposes a boot_retry count option
ostree creates: /etc/kernel/tries with the boot_retry value.

I think these are the same things? The OS builder wants a way to opt-in to boot counting.

ostree creates: /boot/loader/entries/KERNEL_VER.fc27.x86_64+BOOT_RETRY.conf

This part seems right to me; basically ostree shouldn't care what the contents of the filename is today, so we can add the retry and then our equivalent of systemd-bless-boot.service can update the count.

Something like greenboot (or part of the initrd?) would need to decrement the counter at boot.

Another thing we could do here is do the work to test this w/systemd boot, then port to greenboot/grub.

[cgwalters]

As far as metadata associated with a deployment, one thing I could imagine is that we add a generic metadata key to https://uapi-group.org/specifications/specs/boot_loader_specification/

There's e.g. these recommendations for extending os-release

but nothing similar there.