Confusion about LXD versions

Project Discussion LXD Support
1

Hi everyone,

I struggle to understand the versioning of LXD snap packages.

A few days back I updated a VM to 6.7-5c24579 (channel latest/stable).

If fixed one problem I had earlier (sorry, could not answer, topic was closed after 24 hours - the ZFS issue was solved after another upgrade to 6.7-5c24579 and using external tools. Thanks.).

Now I try the same on different VMs. They had 6.7-1f11451 .

I query the available updates, get 6.7-5c24579 (snap info lxd)

but then it installs 6.7-12e2019 after snap refresh.

It feels very inconsistent.

Given that I have to ensure that all VMs in a cluster are the same version and a new VM joining the cluster too - it feels very shaky.

Why these versioning mismatch between asking for versions and installing them?

Regards

Peter

(BTW: Is this hex, and 6.7-12 should be older than 6.7-1f?)

2

BTW: I noticed that one of the three nodes even got updated to 6.7-5c24579 - while the others got upgrade to 6.7-12e2019 .

Can somebody explain what is happening?

3

Hi @petross

I’m glad to hear you resolved the ZFS issue.

I think the confusion here is around two areas:

  1. LXD snap versions
  2. Snap progressive releases

LXD snap version

The LXD snap version is made up of two parts:

<release version number>-<packaging commit hash>

E.g. 6.7-5c24579

So a snap version contains both the git tag version number of the LXD source, as well as the git commit hash we used from the packaging repo.

Sometimes, after the initial release of a specific LXD version, we may make changes in the packaging repo, which changes the git commit hash. Usually this is for post release cherry-picked fixes or security updates, or if we are updating versions of software bundled in the snap that isn’t LXD itself (for example the ZFS userland tools).

So that is why the packaging commit hash can change for the same release version.

For LTS releases, we publish “interim” notes on these changes.

You can subscribe to release notifications in the News section of the forum:

Snap revisions and progressive releases

The other thing you may see is the snap revision (this is the number in brackets when running snap info lxd).

A snap revision is a specific build of the LXD snap, and it increases each time a build is made for a specific architecture - even if the snap version itself remains unchanged.

If you are seeing that different machines are getting different revisions than each other (and by extension potentially different snap versions) when doing snap refresh, then it is likely down to a snap feature called progressive releases:

You can request when refreshing to jump to the head of the progressive release by using --cohort=+, see https://documentation.ubuntu.com/lxd/latest/howto/snap/#synchronize-updates-for-a-lxd-cluster-cohort

LXD releases and snap management:

A good place to start with understanding LXD releases is here:

https://documentation.ubuntu.com/lxd/latest/reference/releases-snap/

I would also like to draw your attention to:

Which requests you switch away from using the latest/stable channel (our docs no longer mention it too, and the default track is 5.21). As you’re on latest/stable now I would request you snap refresh lxd --channel=6/stable so that you will roll onto the next LTS and not be on a forever rolling release.

And for more practical advice on managing the LXD snap see:

https://documentation.ubuntu.com/lxd/latest/howto/snap/

I hope this helps!

4

Thank you. Too late for me tonight, it’s bed time in Melbourne, Australia, but I definitely will check the details and hopefully get it right. It makes sense.

Thank you

Peter

1 Like