search

ostreedev / ostree

Operating system and container binary deployment and upgrades
https://ostreedev.github.io/ostree/
Other
1.27k stars 291 forks source link

extensible metadata on deployments #3032

Open cgwalters opened 1 year ago

cgwalters commented 1 year ago

As prep for https://github.com/ostreedev/ostree/issues/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 commented 11 months ago

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 commented 11 months ago

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

cgwalters commented 11 months ago

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

jmarrero commented 10 months ago

we discussed turning composefs for Fedora ELN first.

cgwalters commented 9 months ago

One thing that happened with https://github.com/ostreedev/ostree/pull/3114/#discussion_r1420552680 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 commented 3 months ago

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 commented 3 months ago

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:

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 commented 3 months ago

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

cgwalters commented 3 months ago

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 commented 2 months ago

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.