frontend for systemd-sysext

[cgwalters]

Let's add first class support for systemd-sysext - but instead of being DDI oriented we fetch and upgrade them from a registry.

Something like:

$ bootc sysext -M add quay.io/examplecorp/exampleos-debugtools:latest

-M here means to automatically run systemd-sysext merge after the operation. We'd store the sysexts in /var/lib/extensions by default. Other operations:

$ bootc sysext rm <ext>
$ bootc sysext rm --all

These would only remove sysexts that we "own" or write.

Also, bootc upgrade by default should error out if a target sysext is incompatible.

---

Original issue:

I think it would make sense to support functionality similarly to https://www.freedesktop.org/software/systemd/man/systemd-sysext.html - we could even use that as a backend, though it needs some design around interactions eventually lowering "live apply" type flows.

A strawman could look like:

$ bootc overlay add quay.io/examplecorp/seattle-manufacturing:wifi

That would add a new container image that would be dynamically unioned with the host's rootfs - on updates, we reapply both - and we'd also verify compatibility and fail if e.g. they appeared somehow incompatible. (A lot of potential things to do in "verify compatibility...")

[vrothberg]

Going through old issues at the moment.

@cgwalters, do you still think dynamic overlays like that make sense? Do you have a concrete use case or user story in mind?

[cgwalters]

@cgwalters, do you still think dynamic overlays like that make sense?

Yes definitely, I've retitled and retargeted this issue to be explictly about a bootc/container-native frontend to sysext, which has a ton of use cases.

[cgwalters]

Also xref rpm-software-management/dnf5#1731

[dustymabe]

Let's add first class support for systemd-sysext - but instead of being DDI oriented we fetch and upgrade them from a registry.

Also, bootc upgrade by default should error out if a target sysext is incompatible.

These two things I think have a lot of overlap with the logically bound container images. Do you see this maybe re-using some of the same mechanisms for delivery/binding?

[cgwalters]

These two things I think have a lot of overlap with the logically bound container images. Do you see this maybe re-using some of the same mechanisms for delivery/binding?

LBIs themselves overlap with the host storage, which gets into #20

Clearly all of these things should be stored/managed consistently. sysexts are designed in a relatively simple way where any tool can just drop things in specified directories, but I think for bootc-managed ones we likely want something more "immutable" (API driven, behind readonly bind mount).