LXD polish for xenial

[John Meinel]

>
> ...
>>
>

>
>> 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
cases where their environment needs custom settings.



> Unlike other providers, lxd exposes no way to use the daily images
>> instead of release images, so at present any machine using lxd
>> containers with juju for the first time will get the xenial beta2
>> image then upgrade basically every package. This issue goes away next
>> week, but gets in the way of testing before then.
>>
> I think some workarounds for this were discussed -- did we have any
> success here? Do we have an issue filed upstream on this?
>

"juju bootstrap ... lxd --config image-stream=daily" should work here. I
have some pieces in place (but not all of them) to allow that sort of thing
to also work for "juju bootstrap ... aws && juju deploy --to lxd:" but its
trickier there, because we haven't been needing to pass this particular bit
of configuration down to containers. We have a way to do it, it just needs
time to get it done.



>
>
>>
>> In a related note, the lxc container handling in juju manages images
>> on the state server, but from what I see of the lxd code, each
>> deployed machine will fetch images from cloud-images.ubuntu.com and
>> keep a separate set of images. That makes the above problem much worse
>> for any bundle with multiple machines that use containers.
>>
> Same as above. I just want to make sure we don't loose sight of this and
> do our part in reporting it so upstream can seek to resolve at some point.
>

This is one of the known issues today, and is on the list to get done. Its
lower priority today because while it is important, the deploy does still
succeed, it just isn't as efficient, and we're currently focused on
correctness issues.

John
=:->


>
>
>
> --
> Juju-dev mailing list
> Juju-dev at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20160419/7ea01d75/attachment-0001.html>