Juju 2.x bootstrap on LXD broken (regular bridge, no NAT)

[Andrew Wilkins]

On Mon, Jan 23, 2017 at 6:54 PM Toubeau, Anthony <anthony.toubeau at intel.com>
wrote:

> Hello all,
>
> I'd like to bring to your attention a currently broken bootstrapping
> scenario:
> Local deployment through LXD using a standard bridge instead of the usual
> LXD provided lxdbr0.
>
> As a development vehicle, a Juju install was planned reusing the
> LXD-host's network. This implies having the Juju agent plus the future
> charms on the same subnet as the actual LXD host.
> As detailed in Bug 1633788 (https://bugs.launchpad.net/juju/+bug/1633788),
> the LXD-host's gateway is assumed (based on the current code) to be
> providing the tools for the actual bootstrapping.
>
> But, in the "non-lxdbr0" case let's say, the actual gateway may only be a
> simple DHCP provider for example, hence leading to a failed deployment.
>
> Reference:
> https://github.com/juju/juju/blob/staging/provider/lxd/environ_raw.go#L140
>
> // getRemoteConfig returns a lxdclient.Config using a TCP-based remote
> // if called from within an instance started by the LXD provider.
> Otherwise,
> // it returns an errors satisfying errors.IsNotFound.
> func getRemoteConfig(readFile readFileFunc, runCommand runCommandFunc)
> (*lxdclient.Config, error) {
>     [...]
>
>     // Read here...
>     hostAddress, err := getDefaultGateway(runCommand)
>
>     [...]
>     return &lxdclient.Config{
>         lxdclient.Remote{
>             Name:          "remote",
>             Host:          hostAddress,
>             [...]
>         },
>     }, nil
>
>
> Is this behavior an assumed trend or could we consider fixing it to allow
> this sort of "localhost-based" deployments without NAT?
>

A workaround has been implemented in the 2.1 branch, here:

https://github.com/juju/juju/commit/19bf802db6511d2081369da2a3fe9b13f1bcb9fd

To use this workaround, please see the comments on
https://bugs.launchpad.net/juju/+bug/1640455. I'll mark that bug as a
duplicate of #1633788 now.

This is just a workaround though. We can go (and probably should) go back
to doing what we were doing. That was also imperfect: there was a built-in
assumption that the host's address would never change. The ideal solution
requires that LXD be changed; changes which got bumped this cycle.

I'll look at reverting the default behaviour ASAP, if nobody else gets to
it first.

HTH,
Andrew


> Many thanks in advance,
> Anthony
> ---------------------------------------------------------------------
> Intel Corporation SAS (French simplified joint stock company)
> Registered headquarters: "Les Montalets"- 2, rue de Paris,
> 92196 Meudon Cedex, France
> Registration Number:  302 456 199 R.C.S. NANTERRE
> Capital: 4,572,000 Euros
>
> This e-mail and any attachments may contain confidential material for
> the sole use of the intended recipient(s). Any review or distribution
> by others is strictly prohibited. If you are not the intended
> recipient, please contact the sender and delete all copies.
>
>
> --
> Juju mailing list
> Juju at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju/attachments/20170123/c70b691e/attachment.html>