Re: sysupdate: Limit update to at most one major version
Continuing in https://github.com/systemd/systemd/issues/30695 On Tue, Jan 2, 2024 at 2:06 PM Lennart Poettering wrote: > > On Di, 02.01.24 13:49, Nils Kattenbeck (nilskem...@gmail.com) wrote: > > > > I'd be fine with adding MaxVersion=. Happy to review a patch, merge > > > something like this (at least file an RFE issue) > > > > Should that be inclusive or exclusive? Naming it MaxVersion would > > imply it to be inclusive though an exclusive bound would likely be > > more useful most of the time. One could then specify MaxVersion=1.3.0 > > in their 1.2.x images and once they have an upgrade path they would > > explicitly raise the max version in e.g. 1.2.15. Otherwise they would > > have to specify 1.99.99. > > In retrospect a VersionBound= property with syntax similar to > > ConditionKernelVersion= would have been better though I guess that > > ship has sailed - or is it? Is sd-sysupdate still considered > > experimental? Not sure if this warrants such a change though :shrug: > > We do not allow "=" nor "<" in version strings, as per > https://uapi-group.org/specifications/specs/version_format_specification/. > > Hence we could use that fact and say: "MaxVersion= <=47.11", > "MaxVersion= <47.11" could be used to make the type of version > comparison explicit. This would implement a tiny subset of the > ConditionKernelVersion= logic, and simply default to imply <= if the > comparison is not specified explicitly. > > Of course, a similar logic should then be implemented for MinVersion, > i.e. >= and > > > > Should we continue this discussion on the mailing list or an issue? > > Issue is better. > > Lennart > > -- > Lennart Poettering, Berlin
Re: sysupdate: Limit update to at most one major version
On Di, 02.01.24 13:49, Nils Kattenbeck (nilskem...@gmail.com) wrote: > > I'd be fine with adding MaxVersion=. Happy to review a patch, merge > > something like this (at least file an RFE issue) > > Should that be inclusive or exclusive? Naming it MaxVersion would > imply it to be inclusive though an exclusive bound would likely be > more useful most of the time. One could then specify MaxVersion=1.3.0 > in their 1.2.x images and once they have an upgrade path they would > explicitly raise the max version in e.g. 1.2.15. Otherwise they would > have to specify 1.99.99. > In retrospect a VersionBound= property with syntax similar to > ConditionKernelVersion= would have been better though I guess that > ship has sailed - or is it? Is sd-sysupdate still considered > experimental? Not sure if this warrants such a change though :shrug: We do not allow "=" nor "<" in version strings, as per https://uapi-group.org/specifications/specs/version_format_specification/. Hence we could use that fact and say: "MaxVersion= <=47.11", "MaxVersion= <47.11" could be used to make the type of version comparison explicit. This would implement a tiny subset of the ConditionKernelVersion= logic, and simply default to imply <= if the comparison is not specified explicitly. Of course, a similar logic should then be implemented for MinVersion, i.e. >= and > > Should we continue this discussion on the mailing list or an issue? Issue is better. Lennart -- Lennart Poettering, Berlin
Re: sysupdate: Limit update to at most one major version
> I'd be fine with adding MaxVersion=. Happy to review a patch, merge > something like this (at least file an RFE issue) Should that be inclusive or exclusive? Naming it MaxVersion would imply it to be inclusive though an exclusive bound would likely be more useful most of the time. One could then specify MaxVersion=1.3.0 in their 1.2.x images and once they have an upgrade path they would explicitly raise the max version in e.g. 1.2.15. Otherwise they would have to specify 1.99.99. In retrospect a VersionBound= property with syntax similar to ConditionKernelVersion= would have been better though I guess that ship has sailed - or is it? Is sd-sysupdate still considered experimental? Not sure if this warrants such a change though :shrug: Should we continue this discussion on the mailing list or an issue? Kind regards, Nils
Re: sysupdate: Limit update to at most one major version
On So, 31.12.23 14:43, Nils Kattenbeck (nilskem...@gmail.com) wrote: > Hello, > > we are currently using sd-sysupdate to roll out updates and we're wondering > if there is any possibility to limit updates to consider at most one next > major version. This would allow us to write the software to handle only > data migrations from the previous major version instead of any version > beforehand. > The only thing I have been able to find is MinVersion= which seems to do > exactly the opposite of what we would want to do. I'd be fine with adding MaxVersion=. Happy to review a patch, merge something like this (at least file an RFE issue) Lennart -- Lennart Poettering, Berlin
Re: sysupdate: Limit update to at most one major version
Forwarding to mailing list for future reference. (Also I want to reference this mail in an upcoming mail). On Mon, Jan 1, 2024, 14:31 Nils Kattenbeck wrote: > Hi Adrian > > You can change the URL you check for updates to include the current >> version number, then upload each version to a separate directory. >> >> I.e. instead of putting all the versions in update.example.com/myos, >> you'd put v2 in u.e.c/m/v1 and you'd put v3 in u.e.c/m/v2 and so forth >> > > Brilliant, I did not think of that. > I guess this would fall down when implementing something more complex like > allowing to updating to the next two versions but this already suffices for > my purpose. (In that case it would be possible to serve the images under > multiple directory but that would be a bit ugly, especially when backing it > with something like S3 which does not support symlinks - and also is > disadvantageous for caching with CDNs.) > > Kind regards, Nils > >>
sysupdate: Limit update to at most one major version
Hello, we are currently using sd-sysupdate to roll out updates and we're wondering if there is any possibility to limit updates to consider at most one next major version. This would allow us to write the software to handle only data migrations from the previous major version instead of any version beforehand. The only thing I have been able to find is MinVersion= which seems to do exactly the opposite of what we would want to do. Kind regards, Nils
