Then I guess I don't understand why it worked fine up until last week. <div class="gmail_quote"><div dir="ltr">On Tue, Apr 19, 2016, 10:39 AM Tycho Andersen <<a href="mailto:tycho.andersen@canonical.com">tycho.andersen@canonical.com</a>> wrote: </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Tue, Apr 19, 2016 at 01:42:08PM +0000, Nate Finch wrote: > On Tue, Apr 19, 2016 at 7:49 AM John Meinel <<a href="mailto:john@arbash-meinel.com" target="_blank">john@arbash-meinel.com</a>> 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 </blockquote></div>