On Mon, Jan 23, 2017 at 6:54 PM Toubeau, Anthony <[email protected]> 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 > [email protected] > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/juju >
-- Juju mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
