Additional "lts" channel or support for upstream series
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Snappy |
Fix Released
|
Wishlist
|
Unassigned |
Bug Description
So as part of providing snaps for LXD, we'd like the ability to ship a few different builds to our users. With the current channels, we'd do:
- edge: Current git snapshot (untested)
- beta: Tested git snapshots, typically done after new features land
- candidate: Latest upstream stable release soaking/
- stable: Latest stable release after it's sat for a few days in candidate
That however doesn't include something else which we do upstream, LTS releases.
The LXC projects do have LTS releases, which we push out every 2 years (in sync with Ubuntu LTS) and support for 5 years (again, in sync with Ubuntu LTS). Those LTS releases get monthly bugfix and minor improvement releases but do not get any API change or breaking command line changes.
We'd like the ability to ship our latest LTS release through snaps too. The target audience for this being folks who want a very stable, enterprise grade, well supported and documented LXD experience for their compute workloads. We don't want to default to this for our snap (so stable isn't a good fit), but we'd like to be available as an opt-in thing for our users.
Some ways we could do this:
- Add a new "lts" channel. Which would sit above "stable" but require the user to opt into.
So a user running "snap install lxd" would get the stable channel, but one could do "snap install lxd --lts" to opt into the lts channel.
If there's nothing in the lts channel, it'd simply track the stable channel until such time as a lts build is available.
- Add the concept of "series" to snapd. Making it possible to have a "2.0" series which the usual set of channels. One series would be set as the default, selecting another one would be opt-in.
As far as the user experience, this would make the following work:
- snap install lxd => stable of current series
- snap install lxd --series=2.0 => stable of 2.0 series
- snap install lxd --series=2.0 --edge => edge of 2.0 series
On top of allowing testing of future LTS builds, this would also be a pretty good fit for other software which supports a few different series in parallel (such as OpenStack).
- Ship two snaps, one called "lxd" and one called "lxd-lts".
To make this viable, we'd need a way to allow the lxd-lts snap to co-own the "lxd" and "lxc" toplevel command names with the "lxd" snap.
Besides the obvious conflicts we'd get into should someone attempt to install both of them together, this would also make it much harder for a user to switch from "lxd-lts" to "lxd" due to snap storage being different.
- Use a different account for the lts snap, so something like "lxd@linuxconta
Anyway, this isn't something that's preventing us to work on the existing LXD snap. For now we'll just be targeting the latest upstream release and tell folks who really want the LTS build to stick to normal packages. But some solution to this problem would allow us to entirely move to snaps for LXD distribution and cover all our users use case.
tags: | added: landscape |
tags: | added: nova-lxd openstack |
Changed in snappy: | |
status: | New → Triaged |
importance: | Undecided → Wishlist |
Series of snaps is necessary for commercial applications as well that have multiple supported releases simultaneously such as Landscape.
OpenStack is another example of a suite of applications that has multiple supported releases at a given time.
The ability to upgrade between these supported releases means named based versioning doesn't work.