Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

sd-sysupdate: Support phased rollout #30855

Open
septatrix opened this issue Jan 9, 2024 · 0 comments
Open

sd-sysupdate: Support phased rollout #30855

septatrix opened this issue Jan 9, 2024 · 0 comments
Labels
RFE 🎁 Request for Enhancement, i.e. a feature request sysupdate

Comments

@septatrix
Copy link
Contributor

septatrix commented Jan 9, 2024

Component

other

Is your feature request related to a problem? Please describe

It is often desirable to perform a phased rollout (e.g. first 2%, then 15%, then 100%) of updates to catch potential regressions early on.

Describe the solution you'd like

Add a new wildcard to match a percentage (from 0 to 100, both¹ inclusive). If absent this shall default to 100%.

Upon discovering a candidate, a hash shall be calculated using its version and the machine-id as the input. Part of this hash is then compared against the rollout threshold. If the threshold is reached the candidate shall be considered for automatic updates. If it is not reached, the candidate shall still be listed for manual selection.

// Consider for automatic updates if the following is true.
(sd_id128_get_machine_app_specific(<version>) & 0xFFFF) / 0xFFFF < threshold

¹ Percentage of 0 would allow for manual installation without automatically installing an update on any other devices.

Describe alternatives you've considered

  • The server could implement some logic and expose SHA256SUM files containing different files. However it has no possibility to differentiate clients so would have to go by IP address etc to differentiate them. Explicitly including the machine-id as part of the transfer URL is possible but not desirable as it should not be exposed over the network.
  • An additional third-party client application could implement this logic and call sysupdate manually. As phased rollouts are a common scenario it makes sense to integrate this within sd-sysupdate itself.

Open points for discussions:

  • Should fractional percentages be supported? This might be desirable for very slow rollouts, i.e. 0.01%...?
  • Decide whether the component name should also be part of the hash input. Otherwise version vX.Y of component foobar would always be updated in the same point of a rollout as the system/default component vX.Y. This might or might not be desirable, depending on whether or not the components belong together. If they do, they should likely be part of the same definition group. Omitting the component name should however be the safer and more conservative apporach.
  • Should a flag to allow clients to always/never consider phased updates be added? Apt for example supports APT::Get::{Always,Never}-Include-Phased-Updates
  • Stateless systems (no persistent machine-id) which are expected to reboot frequently (within the duration of a phased rollout) have an increased chance to get updates as they can "try" with different machine-ids. This would be resolved with Obtain machine-id from SMBIOS, DT, or TPM (on bare metal) #30707

Implementation in Debian: https://wiki.debian.org/DebianRepository/Format#Phased-Update-Percentage
Mailinglist thread: https://lists.freedesktop.org/archives/systemd-devel/2024-January/049891.html

The systemd version you checked that didn't have the feature you are asking for

255

@septatrix septatrix added the RFE 🎁 Request for Enhancement, i.e. a feature request label Jan 9, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
RFE 🎁 Request for Enhancement, i.e. a feature request sysupdate
Development

No branches or pull requests

2 participants