MAAS hardcodes LXD channel=latest for LXD VM host

Bug #1993090 reported by Nobuto Murata
16
This bug affects 2 people
Affects Status Importance Assigned to Milestone
MAAS
Triaged
Medium
Unassigned

Bug Description

maas: 1:3.2.6-12016-g.19812b4da-0ubuntu1~20.04.1

At this moment, MAAS has channel=latest for LXD snap in vendor_data to configure LXD vmhost.

https://git.launchpad.net/maas/tree/src/metadataserver/vendor_data.py?id=95c09efafc46cfd755f90bc51ab76965afe4c1c8#n227
> "snap install lxd --channel=latest",
> "snap refresh lxd --channel=latest",

If I'm not mistaken, MAAS and LXD have different release cadences so LXD can release a major version with some backward incompatibility and it can break the LXD VM host feature in MAAS.
e.g. https://bugs.launchpad.net/maas/+bug/1988759

It would be nice if MAAS pins LXD to a known working channel per a MAAS release. i.e. 5.4/stable without a fix to a regression above, 5.6/stable with the fix.

tags: added: bug-council
Bill Wear (billwear)
Changed in maas:
status: New → Triaged
importance: Undecided → Low
Revision history for this message
Jerzy Husakowski (jhusakowski) wrote :

MAAS points to latest LXD because the support window for a fixed version of LXD expires before MAAS support window expires. Since MAAS depends on LXD, MAAS CI needs to test LXD candidate versions, or use LXD tracks with similar long term support. We are leaning toward using the latest & adding CI test.

Changed in maas:
importance: Low → Medium
milestone: none → 3.4.0
tags: removed: bug-council
Revision history for this message
Nobuto Murata (nobuto) wrote :

> MAAS points to latest LXD because the support window for a fixed version of LXD expires before MAAS support window expires.

I totally understand the initial motivation using the latest/stable track of LXD.

However in reality, it's going to be broken at some point for example:

- MAAS X.2 ships a vendor data to install LXD latest/stable which can be translated to Y.0.1.
- VM host provisioning should work on the release date.
- 30 days later, LXD releases a new major version as Z.0.0, which can fail at VM host provisioning because the vendor data is embedded into MAAS X.2 and assumes API of Y.0 series.

Instead of a current workflow, I'm suggesting:

- MAAS X.2 ships a vendor data to install LXD Y.0/stable which can be translated to Y.0.1.
- VM host provisioning should work on the release date.
- 30 days later, even if LXD releases a new major version as Z.0.0, VM host provisioning should work since the vendor data embedded into MAAS X.2 should pick up Y.0.7 or something from Y.0/stable channel.
- MAAS can release X.3 with a refreshed vendor data to switch the default channel to Z.0/stable for installing newer LXD and accommodate changes made in LXD.

> We are leaning toward using the latest & adding CI test.

I'm not sure I'm following how this helps into the situation above. I'd like to emphasize the timing of VM host provisioning feature can be some time after cutting a release. Provisioning failure is one, but managing LXD containers is the next because already provisioned VM host can upgrade LXD to whatever the latest thanks to the snap's unattended upgrades, which might be incompatible with LXD management code embedded into a MAAS release. i.e. even provisioning works, LXD management can break "all of sudden" from an operator point of view.

Alberto Donato (ack)
Changed in maas:
milestone: 3.4.0 → 3.4.x
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.