<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Tue, Apr 19, 2016 at 7:49 AM John Meinel <<a href="mailto:john@arbash-meinel.com">john@arbash-meinel.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">...<br></blockquote></span></div></div></div></blockquote></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
That's probably the cause of the other confusion in the updated docs -<br>
now we *do* want the bridge named lxdbr0 not lxcbr0. If the user<br>
already has lxc setup in some fashion there's a different error from<br>
juju telling them to run the dpkg-reconfigure command. That should<br>
presumably always appear whenever there's no usable bridge.<br></blockquote></span><div>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. </div></div></div></div></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>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.</div><div>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</div></div></div></div></blockquote><div><br></div><div>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.  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 <b>lot</b> of users with a bad first impression.   </div><div><br></div><div>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?</div></div></div>