Then I guess I don't understand why it worked fine up until last week. On Tue, Apr 19, 2016, 10:39 AM Tycho Andersen <[email protected]> wrote:
> On Tue, Apr 19, 2016 at 01:42:08PM +0000, Nate Finch wrote: > > On Tue, Apr 19, 2016 at 7:49 AM John Meinel <[email protected]> > 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 >
-- Juju-dev mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
