Connectivity to the Juju controller not guaranteed in cases where a charm has only one available binding

[Michael Skalka]

In some charms such as cd:~containers/easyrsa/ which are widely deployed there are situations where it is desirable for the service to be in an LXD container and communicate on a network segment that is different than that of the Juju controller which have no routing between them. In these cases we have to specify constraints in a bundle to force Juju to create an interface on both the Juju "controller" space and the desired "communication" space:
...
applications:
...
  easyrsa:
    charm: cs:~containers/easyrsa
    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-space, but will appear as "waiting" in Juju forever.

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.

[Richard Harding (rharding)]

Thanks, it makes sense and we'll see if we can work it into some of the networking work this cycle.

[John A Meinel (jameinel)]

Given our statement "all machines must be routable to the controller
space", I don't think this is ideal. Especially if you consider multi-cloud
controllers and multi-user controllers. (eg, consider JAAS). There is no
reason containers would be on the same network segments as controllers.
It is true that all machines and containers must have a route to
controllers. If it is true on your network topology, you can just add the
model-config causing all machines (and containers) that are provisioned to
end up in that space. (juju set-model-constraints "space=foo")

On Thu, May 23, 2019 at 11:30 PM Michael Skalka <email address hidden>
wrote:

> Public bug reported:
>
> In some charms such as cd:~containers/easyrsa/ which are widely deployed
> there are situations where it is desirable for the service to be in an LXD
> container and communicate on a network segment that is different than that
> of the Juju controller which have no routing between them. In these cases
> we have to specify constraints in a bundle to force Juju to create an
> interface on both the Juju "controller" space and the desired
> "communication" space:
> ...
> applications:
> ...
> easyrsa:
> charm: cs:~containers/easyrsa
> 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-space, but will appear as "waiting" in Juju forever.
>
> 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.
>
> ** Affects: juju
> Importance: Undecided
> Status: New
>
> --
> You received this bug notification because you are subscribed to juju.
> Matching subscriptions: juju bugs
> https://bugs.launchpad.net/bugs/1830270
>
> Title:
> Connectivity to the Juju controller not guaranteed in cases where a
> charm has only one available binding
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/juju/+bug/1830270/+subscriptions
>

[Canonical Juju QA Bot (juju-qa-bot)]

This bug has not been updated in 2 years, so we're marking it Low importance. If you believe this is incorrect, please update the importance.