Connectivity to the Juju controller not guaranteed in cases where a charm has only one available binding
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Canonical Juju |
Triaged
|
Low
|
Unassigned |
Bug Description
In some charms such as cd:~containers/
...
applications:
...
easyrsa:
charm: cs:~containers/
constraints: controller-space
bindings:
client: communication-space
num_units: 1
to:
- lxd:0
...
This presents some very bad UX for individuals who are not aware of this limitation, as deploying that service without the constraint will cause Juju to happily launch a container it can never communicate with. The container will be created on the host, given an IP address on the communication-
It would be advantageous to deploy containers with an interface on the "controller" space by default, and any additional bindings layer interfaces on top of that. We can be reasonably assured that any deployed physical hosts already have an interface on that network, they are talking to Juju after all.
Thanks, it makes sense and we'll see if we can work it into some of the networking work this cycle.