lxd-agent-loader/lxd-installer SRU exception policy review

[Robie Basak]

Hi Simon,

Thank you for working to make users' experience of LXD better for Ubuntu
users!

On Thu, Oct 24, 2024 at 01:07:29AM +0000, Simon Déziel wrote:
> I would like to request an SRU exception [1] for the lxd-agent-loader
> and lxd-installer packages in all supported Ubuntu releases. I have
> created a wiki page [2] that outlines everything I believe is relevant
> to this SRU exception.

I agree that some changes to the lxd experience probably should fit
under our "For Long Term Support releases we sometimes want to introduce
new features" justification for SRUs to stable Ubuntu releases[1]. Note
though that this isn't an "exception" as such since existing SRU policy
permits this.

We do need to ensure the condition "They must not change the behaviour
on existing installations". I would further extend this to ensure that
we do not change behaviour of *redeployments* since this is also a
common use case for server users (eg. CI that uses LXD).

I note that both lxd-agent-loader and lxd-installer are pretty minimal
"3.0 (native)" packages. Changes should be easy to review. The easiest
way to ensure the above constraints would be a full review of the
changes being applied during both sponsorship and upload, and SRU review
for the same thing. To that end, I'm not sure any kind of routine
process that skips a full code review makes sense. Can we instead review
requested changes in SRUs on a case-by-case basis?

This wouldn't preclude you from maintaining (essentially) the same
source tree of these packages across all supported Ubuntu releases.
You'd need to ensure no changes to behaviour for existing Ubuntu users
whichever way you do it. I'm just saying that case-by-case review
is probably the easiest and smoothest way of achieving that.

Normally other packages bound to a regular SRU cadence but without
changing existing user behaviour (eg. cloud-init) have to be very
careful to maintain this in every upstream change they make. This does
compromise engineering velocity when developing new features and new
behaviours. Either way, you'd need to be making the same commitment. I
would question though if this is really necessary given that engineering
burden.

For example, I see a change[2] in lxd-installer that changes some
default behaviour to failure instead of falling back to the default snap
channel for lxd. It may be the case that in practice this won't result
in behaviour change to users, but that's the kind of thing that we need
to be careful about, and therefore needs reviewing carefully. Ideally
the code change would be written in a way that makes it easier to
validate that there really will be no change to user behaviour.

To proceed, I suggest that you start by reviewing to consider if all the
changes to both lxd-installer and lxd-agent-loader would be acceptable
to SRU for each Ubuntu release in terms of (the lack of) changes to
behaviour. This might involve making some code changes to make it easier
to demonstrate that this is the case. If after careful review you think
that this is the case and demonstrable by code review, then the SRU team
could also review to confirm that, and then we'd be able to update both
packages in all stable releases as a one-off exercise.

Next time, we'll have a baseline to review against then. If this becomes
annoyingly repetitive then we could consider some kind of standing
agreement to skip some parts of the review at that point.

None of this precludes us having some documentation that explains this
plan, of course.

Does this work for you?

Robie

[1] https://canonical-sru-docs.readthedocs-hosted.com/en/latest/reference/requirements/#other-safe-cases
[2] https://git.launchpad.net/ubuntu/+source/lxd-installer/diff/lxd-installer-service?id=b9a2b3c3461eaf73976c069432782329465f579d
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <https://lists.ubuntu.com/archives/ubuntu-release/attachments/20241024/51031d9d/attachment.sig>