On Tue, Jan 24, 2017 at 12:54 AM John Meinel <j...@arbash-meinel.com> wrote:
> 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? > The workaround involves adding a new cloud, as described in https://bugs.launchpad.net/juju/+bug/1640455, Comment #9 and down. > 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/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@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
