juju assumes lxd always available on machine nodes

[Ian Booth]

When the machine agent starts up, it records in state the supported containers (lxd, kvm). This is used by the container broker worker to determine if the lxd infrastructure should be initialised.

It seems we are hard coding that lxd is always supported

supportsContainers := container.ContainersSupported()
if supportsContainers {
  supportedContainers = append(supportedContainers, instance.LXD)
}

^^^ ContainersSupported() is true for vm machines.

This we always attempt to start the LXD broker. But if LXD is not installed, we get an error

ERROR juju.worker.dependency engine.go:693 "broker-tracker" manifold worker returned unexpected error: cannot create instance broker: creating LXD container manager: Get "http://unix.socket/1.0": dial unix /var/lib/lxd/unix.socket: connect: no such file or directory

Over and over again in the logs. Not sure without looking deeper if this bounces the whole agent or not. But if it does, it would disrupt everything.

See bug 1984060. There's symptoms of leadership claims erroring out - maybe the agent bounce leads to leadership churn which can't keep up. Needs investigation.

We should not claim lxd support for a machine unless lxd is installed.

[Joseph Phillips (manadart)]

I believe this should be fixed with:
https://bugs.launchpad.net/juju/+bug/1934176

If you look at:
https://github.com/juju/juju/pull/14381

You see that the error annotation no longer exists.

There will however be problems if someone attempts to provision a LXD container on such a host, as HasSupport will still return true. I will look into this part.

[Joseph Phillips (manadart)]

Better detection:
https://bugs.launchpad.net/juju/+bug/1986877

[Haw Loeung (hloeung)]

I think you mean https://github.com/juju/juju/pull/14484 rather than linking to this bug itself ;)

[Joseph Phillips (manadart)]

Indeed. Thanks.