For your workaround, where does spec.Endpoint get filled in? By the user as part of bootstrap-contraints? or by juju as a default value? I don't see anything in your patch, which sounds like you would have to do: juju bootstrap --bootstrap-constraints endpoint=HOSTIP lxd ... if you were working on a non-NAT bridge.
Is that true? John =:-> On Mon, Jan 23, 2017 at 3:07 PM, Andrew Wilkins < andrew.wilk...@canonical.com> wrote: > On Mon, Jan 23, 2017 at 6:54 PM Toubeau, Anthony < > anthony.toub...@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/19bf802db6511d2081369da2a3fe9b > 13f1bcb9fd > > 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@lists.ubuntu.com >> Modify settings or unsubscribe at: https://lists.ubuntu.com/ >> mailman/listinfo/juju >> > > -- > Juju mailing list > Juju@lists.ubuntu.com > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/juju > >
-- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
