Additional "lts" channel or support for upstream series

Bug #1611424 reported by Stéphane Graber
18
This bug affects 1 person
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/smoketesting
 - 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@linuxcontainers-lts" but that feels like a bit of a hack and would also be a problem as far as command names on the system.

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.

Revision history for this message
Dean Henrichsmeyer (dean) wrote :

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.

tags: added: landscape
Revision history for this message
Mark Shuttleworth (sabdfl) wrote : Re: [Bug 1611424] Re: Additional "lts" channel or support for upstream series

We do have series in snapd, but it's tied to the base OS. In other
words, we can easily let you separate lxd-for-14.04 from lxd-for-16.04,
but we won't add a snap-specific series.

Revision history for this message
Stéphane Graber (stgraber) wrote :

Right, the snapd series for base OS may be very useful for some people. On the LXD case I don't expect us to need this as the same snap will most likely work on 14.04 and 16.04 (if our existing backport is any indication).

Having series or a similar concept at the snap level is what we're really after here, so we can have both the LTS release of LXD (2.0.x) and the latest stable release available to our users.

The same would apply to the OpenStack snaps where you'd be able to choose between the Liberty, Mitaka or Newton version of any of the snaps and then choose what channel you want for those.

For LXD, we'd probably be running two such "series":
 - current (or just no series name, so the default one)
   - stable (current stable release)
   - candidate (beta/rc of next stable)
   - beta (latest tested git build)
   - edge (untested git build from master branch)
 - 2.0
   - stable (latest stable release, 2.0.3 right now)
   - candidate (next stable release, used for a few days before pushing to stable)
   - beta (latest tested git build)
   - edge (untested git build from the stable-2.0 branch)

I'd expect a similar structure to make sense for other projects which have more than one actively maintained release (especially for those doing LTS releases).

To be clear, this isn't a blocker for us right now. We're focusing on the latest stable release for our snap right now and are happy to tell users who need the LTS version to use a PPA or other distro packages until such time as we have a mechanism to cover their use case with snaps.

Revision history for this message
James Page (james-page) wrote :

I think we have similar requirements for OpenStack; specifically I'd like to have the same structure for each openstack series being supported at a given point in time

- newton
 - edge: Current git snapshot (untested)
 - beta: Tested git snapshots, typically done after new features land
 - candidate: Latest upstream stable release soaking/smoketesting
 - stable: Latest stable release after it's sat for a few days in candidate

- mitaka
 - edge: Current git snapshot (untested)
 - beta: Tested git snapshots, typically done after new features land
 - candidate: Latest upstream stable release soaking/smoketesting
 - stable: Latest stable release after it's sat for a few days in candidate

....

and so on (today this would include liberty and kilo as well) - this could be achieved with a naming schema for snaps which includes the openstack release name.

Revision history for this message
Mark Shuttleworth (sabdfl) wrote :

We also have the concept of epochs or era's, which were conceived as a
way to deal with profound changes in on-disk data formats but could just
as easily serve to handle the sort of one-way upgrade scenario you are
thinking about here.

The background is that we know that snaps will upgrade from version 2 to
version 3, and that it may not be possible to go backwards after doing
that. Also, we know that a disconnected device may not see every
generation. For example, a device might ship with version 1 of some
software, then miss version 2 and connect to the store when the stable
version is now 3, but be unable to handle the upgrade from version 1 to
version 3.

So epochs/eras were sketched out as a way to deal with these big
transitions. In the example above, the device would jump to a revision
of the snap that can handle both version 1 and 2 formats, then jump
again to a version that can do 2 and 3 before going to the latest stable
version 3.

If we made these epochs into things that users can view and think about
and consciously switch between, then we would have the sort of
experience James and Stephane are describing. I don't think it's a
perfect fit, but it may be a useful new lens to look at the epoch work
through.

Mark

cargonza (cargonza)
tags: added: nova-lxd openstack
Revision history for this message
Stuart Bishop (stub) wrote :

PostgreSQL has separate snaps for postgresql93, postgresql94, postgresql95, postgresql96 and soon there will probably be postgresql10. If this was all a single namespace with different series, I think it would improve usability and open the door to major upgrades between series and gracefully handling EOL of series support.

Revision history for this message
Mark Shuttleworth (sabdfl) wrote :

This is the intention - one 'postgres' snap with multiple, custom LTS
channels, like:

 latest
 9.3
 9.4
 ...
 10.0

Each of those could have stable, candidate, beta and edge revisions.

Mark

Michael Vogt (mvo)
Changed in snappy:
status: New → Triaged
importance: Undecided → Wishlist
Revision history for this message
Stéphane Graber (stgraber) wrote :

Tracks cover all of this now.

Changed in snappy:
status: Triaged → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.