Comment 2 for bug 1993090

> 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.