You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Merge pull request juju#11480 from achilleasa/dev-configurable-channel-for-lxd-snap
juju#11480
## Description of change
This PR enables juju operators to specify the snap channel used to install lxd on a **per model** basis via a new model configuration option called `lxd-snap-channel` (defaults to `latest/stable`).
The new option comes into play as follows:
- When installing lxd as a snap dependency in cosmic+ (IIRC, this happened with eoan/s390 images)
- When **setting up container support** on a machine that comes with lxd pre-installed (most of the images that juju uses).
The first case is simply handled by passing the configured lxd channel to the dependency resolution system which then injects it into `snap install lxd` commands.
The latter case is handled by first introspecting the currently tracked channel and comparing it to the one specified by the operator (or the default). In case of a mismatch, the code will first switch to the selected channel (`snap refresh --channel BLA lxd`) before performing the rest of the snap-related setup steps (e.g. configure proxies etc.)
Note that the above channel change will only occur when you attempt to deploy an **lxd workload**. If you simply spin up a new machine via `juju add-machine` it will still be using whatever lxd snap comes pre-installed with it _until_ you actually deploy something to it (see QA steps for an example).
Finally, our images seem to use the `track/risk/branch` channel format where branch is tied to the release (e.g. `latest/stable/ubuntu-20.04` on focal). To avoid redundant `snap refresh` calls while still being able to use a sane default for the model option, the code will compare the model setting and the reported tracking channel via a **prefix match** check.
Caveats: changes to this model setting only apply to machines with no pre-existing lxd-based workloads. The setting has no effect to existing machines with already deployed lxd workloads; these machines will use whatever lxd snap was initially made available to them. Implementing this would probably require a worker but operators can still use `juju ssh` to run the `snap refresh` commands manually if they need to.
## QA steps
```console
$ juju bootstrap lxd test --no-gui
$ juju model-config lxd-snap-channel
latest/stable
$ juju model-config lxd-snap-channel=3.23/edge
# Start some machines and check their current lxd version
# This should match whatever is *pre-installed* in the image
# (note: bionic still uses apt)
$ juju add-machine --series=bionic
created machine 0
$ juju ssh 0 'sudo which lxd'
/usr/bin/lxd
$ juju add-machine --series=eoan
created machine 1
$ juju ssh 1 'sudo which lxd'
/snap/bin/lxd
$ juju ssh 1 'snap info lxd | grep tracking:'
tracking: latest/stable/ubuntu-19.10
$ juju add-machine --series=focal
created machine 2
$ juju ssh 2 'which lxd'
/usr/bin/lxd
$ juju ssh 2 'snap info lxd | grep tracking:'
tracking: latest/stable/ubuntu-20.04
# Deploy an lxd workload on machines 0 (bionic) and 1 (eoan)
# and wait for everything to come up.
$ juju deploy cs:~jameinel/ubuntu-lite-7 --to lxd:0
$ juju add-unit ubuntu-lite --to lxd:1
# Now check the lxd versions on machines 1(eoan), 2 (focal)
# NOTE: it may take a few moments for the snap to update! Be patient ;-)
# Notice that the focal machine still uses its built in snap as it currently has no lxd workload
$ juju ssh 1 'snap info lxd | grep tracking:'
tracking: 3.23/edge
$ juju ssh 2 'snap info lxd | grep tracking:'
tracking: latest/stable/ubuntu-20.04
# Now change the model config again and deploy an lxd workload to machine 2 (focal)
$ juju model-config lxd-snap-channel=4.0/edge
$ juju add-unit ubuntu-lite --to lxd:2
# Also deploy an lxd workload to a new machine
$ juju model-config default-series=eoan
$ juju add-unit ubuntu-lite --to lxd
# Finally check all lxd versions again after everything settles
```
## Documentation changes
We need to document the new model config option and the series that it affects (essentially, everything after bionic)
0 commit comments