LXD polish for xenial

Tycho Andersen tycho.andersen at canonical.com
Tue Apr 19 14:39:15 UTC 2016


On Tue, Apr 19, 2016 at 01:42:08PM +0000, Nate Finch wrote:
> On Tue, Apr 19, 2016 at 7:49 AM John Meinel <john at arbash-meinel.com> wrote:
> 
> > ...
> >>>
> >>
> >
> >>
> >>> That's probably the cause of the other confusion in the updated docs -
> >>> now we *do* want the bridge named lxdbr0 not lxcbr0. If the user
> >>> already has lxc setup in some fashion there's a different error from
> >>> juju telling them to run the dpkg-reconfigure command. That should
> >>> presumably always appear whenever there's no usable bridge.
> >>>
> >> The flip flopping back and forth on the bridge name is going to cause
> >> havoc even after release. Do we have clear direction now from LXD on how
> >> they plan to handle the competing network bridge names? I understand we're
> >> now saying a dpkg-reconfigure is required, but I'm not clear if / when we
> >> plan to make this easier.
> >>
> >
> > So, LXD is going to be installed-by-default on Xenial. Which means that
> > everyone will always have it installed. However, that leads to a problem
> > with having a "standard" subnet dedicated to LXD. While it works for lots
> > of people, there are plenty of cases where that subnet would already be in
> > use elsewhere (in say a company's internal LAN). Which means LXD chose to
> > go with link-local addresses by default. AIUI that means that the
> > containers can talk to the host (and probably the host can route them to
> > the public internet?) but they aren't able to talk to other containers or
> > have inbound traffic.
> > My personal hope is that the dpkg-reconfigure steps can provide a 70%-case
> > safe default set of addresses (possibly using autodetection), and give a
> > nice wizard to help people, while still allowing them to override it in case
> >
> 
> I really fear for what this will do to adoption.  I feel like we're
> throwing the common "it just works" case out the window to enable a very
> small edge case to work slightly better.  I'd much rather have defaults
> where juju/lxd just works with most common setups.  For the one little
> exception - if the network on your corporate LAN conflicts - we give a nice
> error message and give the user tools to reconfigure.

The problem here is that there's no way to detect this case (e.g. what
if the network in question is routed behind your default gateway
somehow?). Things just break, and it can be difficult for people to
figure out why.

LXD's bridge setup defaults to ipv6 link local with an HTTP proxy that
allows apt-get to work. The current dpkg-reconfigure prompts will
suggest reasonable values if you decide you want to enable ipv4.

> Making everyone
> configure their network (not the easiest or friendliest task even for
> people on our own team), is surely going to cause us to lose a *lot* of
> users with a bad first impression.
> 
> LXD is our code.  Juju is our code.  Surely we can code/configure the two
> to work together such that it just works for the 95% case?

I assure you we're aware of this. Unfortunately there's not a good
answer.

Tycho



More information about the Juju-dev mailing list