systemd-sysupdate support for slow rollout (aka A/B testing)

[Nils Kattenbeck <nilskemail@xxxxxxxxx>]

Hey everyone,

does sysupdate currently support any way to slowly roll out updates
where the server providing the files can be in control? This would be
used to slowly make a new version available and have it at e.g. 1%
adoption for a day to monitor regressions before increasing the
coverage. I was unable to find any information about it in the
documentation.

Currently it seems like I would have to implement a different service
which calls the sysupdate binary (or uses dbus once #28134 has landed)
and then decides based on some other information.

One idea I had would be that systemd-pull could send the machine-id
based on which the server could then decide to provide the newer file
(e.g. last two chars == "00" would roll it out to ~1/255). Though I am
not sure if sd-pull is supposed to be "anonymous", i.e. do not provide
this identifying information. Another drawback of this would be that
stateless systems which reboot often get a new machine-id each boot,
thus having an increased chance to get the newer version.

Does anything like this already exist or is planned? Or should that be
done by different applications on the client side?
I also remember there being a discussion about plugging in different
sd-pull like implementations/backends[1] to support delta updates,
other transports, or TLS client authentication. This could at least be
adapted to support my idea to send the machine-id as an HTTP header
(e.g. X-MACHINE-ID).

Greetings, Nils

[1] https://lists.freedesktop.org/archives/systemd-devel/2023-February/048856.html