[systemd-devel] systemd-sysupdate and systemd-sysext images

[Thorsten Kukuk]

Hi Adrian,

On Thu, Oct 31, 2024 at 5:50 PM Adrian Vovk <adrianvovk at gmail.com> wrote:
>
> On Thu, Oct 31, 2024 at 11:30 AM Thorsten Kukuk <kukuk at suse.com> wrote:
> >
> > Hi Adrian,
> >
> > On Thu, Oct 31, 2024 at 3:43 PM Adrian Vovk <adrianvovk at gmail.com> wrote:
> > >
> > > Hi Thorsten,
> > >
> > > If I understand correctly, you're looking for a way to distribute sysexts such that they can be enabled/disabled, and they're updated in lock step with each other and the base OS. Is that correct?
> >
> > No, we don't have an "image" for the OS, the installation is either
> > built from RPMs or an OCI image.
> > Since we have a read-only root filesystem and you need to reboot if
> > you want to install debugging tools, I wanted to provide them as a
> > sysext image. I know, the RPM dependency is tricky in this case, this
> > will only work with a limited number of packages, but that's another
> > problem.
>
> You're going to have a hard time keeping things in version lock-step
> then. What happens if the underlying base system is updated and the
> sysext isn't? You'll have broken dependencies.

No, this is a no brainer. If the base system gets updated, we make
sure that the sysext images get updated, too. Since we publish
(nearly) daily a new snapshot with a new OS version, which will
include new sysext images, this works fine and systemd-sysext will
apply the image which matches the installed version. Our build and
release chain will make sure that this fits together. We have more
than enough experience with that.
The only problem is, if people don't have the default minimal base
system installed. That's a generic problem if you use RPMs or OCI
images for the Base OS and not images as defined by systemd.

But I think you will run into problems, if third parties try to build
sysext images for Flatcar.

> Anyways, you don't need to have an image-based OS to use optional
> features. Sure, your sysexts won't be version-locked to the base
> system, but at least they'll be version-locked amongst each other.
> Unless I'm still misunderstanding your situation and that's expressly
> an anti-goal for you.

The "feature images need to have the same version number" from the
documentation is not doable.
This works sysext images we build together, but latest if people want
to provide their own sysext images, there is no way that you can sync
the version number.
And with this "all sysext images need to have the same version", you
cannot release a critical bug/security fix for one sysext image only,
you always need to release everything with a new version number, even
if nothing changes. This makes updates pretty heavy and unnecessarily
complicated.

The only advantage I see in "features" is that you can pre-deploy
configs with the base OS and people can enable/disable them.
They don't allow you to maintain sysext images from various sources
for a non systemd image based system.

> But yes, this behavior of sysupdate makes sense. systemd-sysupdate is
> a low-level tool that you point at an image and it does its work; it
> has no concept of what that image is. If you want high-level behavior,
> that abstracts across multiple images, then you're looking for
> systemd-sysupdated and updatectl.

Ah, I forgot about that new utility during my vacation...
But updatectl does not solve my problems, see above.
It's still centric about this "there is a base OS image and all
extensions have the same image version", even if it has a nice
interface.

  Thorsten

-- 
Thorsten Kukuk, Distinguished Engineer, Senior Architect, Future Technologies
SUSE Software Solutions Germany GmbH, Frankenstraße 146, 90461
Nuernberg, Germany
Managing Director: Ivo Totev, Andrew McDonald, Werner Knoblich (HRB
36809, AG Nürnberg)