local lxd provider always use the unix socket

[Adam Stokes]

Im running into this issue when both deb package lxd and snap package lxd are installed side by side.

Since Juju only uses the unix socket for bootstrap and I think the https port for state server you either get a collision or juju end up picking the wrong LXD.

I believe I understand why we do it this way for handling remote lxd setups, however, for a local lxd deployment it would be really nice to always just use the unix socket and then I could control which lxd juju uses by altering LXD_DIR.

[Adam Stokes (adam-stokes)]

Just an additional note, having this feature is a huge benefit for giving me the ability to better control the stability of conjure-up by making sure all moving parts are versioned the same as what is run through our CI. Building a snap with everything I need relieves a huge unknown about whether LXD version X is going to work with conjure-up version Y.

A quick win here would be to allow a user to define which LXD api port Juju should connect to since the bootstrap portion already honors the LXD_DIR setting.

[Andrew Wilkins (axwalk)]

As of 2.1.0, we no longer use the Unix socket if you specify an endpoint. If you don't specify an endpoint, but set $LXD_DIR, Juju should honour that.

[Andrew Wilkins (axwalk)]

(More accurately, as of 2.1-rc2)

[Andrew Wilkins (axwalk)]

A couple of other things of note:
 - If you don't specify an endpoint (i.e. you ue the Unix socket), Juju will extract the HTTPS port from the server's configuration, rather than assuming 8443.
 - If you don't specify an endpoint, Juju will not set the core.https_address config if it's already set.

So to use a secondary LXD, you should:
 1. set core.https_address first, to something other than <IP>:8443.
 2. set $LXD_DIR when you bootstrap