provider/lxd: cannot bootstrap when network is bridged
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Canonical Juju |
Triaged
|
High
|
Unassigned | ||
2.2 |
Triaged
|
High
|
Unassigned |
Bug Description
In Juju 2.0, the controllers connect to LXD using the address of the host with TLS auth. We determine the host address by obtaining the address of the default gateway. This only works when the gateway is the host, which is not the case when the network is bridged.
LXD may grow the ability to proxy unix sockets eventually, which would be preferable: the host would inject the LXD socket into the container, and the controller would use the unix socket method instead. This support doesn't exist yet.
In the mean time, we could have the bootstrap process identify the address of the host and inject that into the container as metadata. The container can query /dev/lxd to obtain that metadata. This is prone to the address becoming stale, but that is at unlikely, and can be fixed by the user by updating the container metadata manually.
This is currently unassigned and represents a complete show stopper for anyone attempting to evaluate Juju for enterprise adoption. Can someone point me to the variable name so I can replace the IP detection mechanism with a static value and run my own custom compiled version because this doesn't seem to be getting fixed any time soon.
I can assert that it is useful to actively developed projects like this one that providing a config file override option for internal variable substitution is generally frowned upon and complained about by developers, but somehow always gets used for something in production. That being said, if the variable for the node IP had such an override there would at least be a workaround.
As of right now there is no end in sight to this issue and nobody is assigned to work on it still. I personally had the option of adopting Juju orchestration for a client integration until I ran into this issue. You are losing the support of enterprise customers every day that this issue remains in existence.
Thanks.