You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
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.
¹ Percentage of 0 would allow for manual installation without automatically installing an update on any other devices.
Describe alternatives you've considered
Open points for discussions:
APT::Get::{Always,Never}-Include-Phased-Updates
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
The text was updated successfully, but these errors were encountered: