LXD polish for xenial

[Nicholas Skaggs]

On Mon, Apr 18, 2016 at 2:17 PM, Martin Packman <
martin.packman at canonical.com> wrote:
>
> For the lxd provider, I understand we're resigned to the user having
> to manually configure a bridge for lxd before bootstrap can work.
> Currently the documentation is confused as to what exactly the steps
> are, the release notes refer to these two links:
>
> <https://linuxcontainers.org/lxd/getting-started-cli/>
> <http://insights.ubuntu.com/2016/04/07/lxd-networking-lxdbr0-explained/>
>
> But I think the latest advice is as committed with this change to our
> documentation:
>
> <https://github.com/juju/docs/pull/998/files>
>
> Note that just running dpkg-reconfigure is not enough, you have to
> poke a service or run `lxc` afterwards or you get this error with
> beta4:
>
>     $ juju bootstrap --config default-series=xenial lxd-test lxd
>     ERROR cannot find network interface "lxcbr0": route ip+net: no
> such network interface
>     ERROR invalid config: route ip+net: no such network interface
>
> 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.

> 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?


>
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20160418/ab8bf25d/attachment-0001.html>