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).

[p5]

Been thinking about this after I've started using Bootc more at work.

While having integrations with System Extensions would be pretty cool, I feel it would also be good to have a generic overlay, rather than being tied into a sysext (or maybe this would be a different issue). The main limitation, though it may be a misunderstanding, is that sysexts only work for /usr/, and you need to use confexts - a separate tool - for managing /etc.

I'm now working in a multi-cloud and on-prem environment, and would love to be able to create a single set of vendor-agnostic images, then be able to tell Bootc to layer/overlay additional scratch images on top to apply the cloud vendor specific configurations. These overlays would apply to the same directories that bootc supports deploying to (all except /var?).

AWS have their own ssm-agent and ec2 tools they recommend (and require for some functionality). So does Vmware. And Azure environments probably have something else.

I would like to be able to do the following:

$ bootc switch my-registry.org/bootc/httpd --overlay my-registry.org/bootc-layers/aws
$ bootc switch my-registry.org/bootc/httpd --overlay my-registry.org/bootc-layers/vmware
$ bootc switch my-registry.org/bootc/httpd --overlay my-registry.org/bootc-layers/azure

This deploys the httpd image as usual, but overlays the contents of the aws "layer" on top of the deployed filesystem, without the need to setup additional pipelines and storage. This layer contains any and all binaries or configuration files required to adapt the OS for that deployment.

In more simple cases, these overlays could include the applications themselves (although the recommendation would still to use Quadlets/containers/LBIs):

$ bootc switch my-registry.org/bootc/rhel --overlay my-registry.org/bootc-layers/httpd

A bootc update would update both the system image and overlay images, and allow you to target mutable tags.

Bootc Image Builder would be used to create these cloud-specific images with the required overlays for each platform.