LXD polish for xenial

[Marco Ceppi]

Thanks so much for spending time on this polish! It'll really help our user
experience shine for cost effective dev.

On Mon, Apr 18, 2016, 2:17 PM Martin Packman <martin.packman at canonical.com>
wrote:

> When it comes to using lxd in clouds, as I understand it we've settled
> on retaining the 'lxc' and 'lxd' name distinction in 2.0 - which does
> mean bundles have to be manually changed at present to start using
> lxd. Most of the CI bundle testing is using real bundles out of the
> store, which all still say 'lxc' and therefore don't exercise the lxd
> container code at all.
>

This bit confused me, and I realize this is late in the cycle, but I'd be
remiss if I didn't at least float the though.

I would have expected juju to do the right thing for bundles. With what
you've stated, we now have bundles that won't deploy in 1.25 that will in
2.0 and vice versa despite charms supporting both. This seems like a step
backwards from a UX.

What's the reasons behind this? Will there be a min-juju-version like in
charms? (Hopefully not)

My expectation would have been juju 1.25 for lxc placement produces a lxc-1
container and in 2.0 produces a lxd/lxc-2 container.


> We do have the container networking test which uses 'juju add-machine
> ... lxd:0' - and fails due to the networking setup:
>
> "container networking lxd 'Missing parent for bridged type nic'"
> <https://bugs.launchpad.net/juju-core/+bug/1571053>
>
> That is probably less interesting than the default behaviour without
> the feature flag.
>
> As a separate test, I updated one of our simple bundles just to say
> 'lxd' in two places where it had 'lxc' for a service before. The
> deployment timed out after 24 minutes, where the normal test with lxc
> takes 12 minutes.
>
> The reason for that turns out to be pretty simple. Looking back at the
> lxd provider test, it hung for over 20 minutes just updating packages
> when setting up the first container:
>
>     In container /var/log/apt/history.log
>     Start-Date: 2016-04-15  22:11:16
>     ...
>     End-Date: 2016-04-15  22:33:03
>
> 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.
>
> 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.
>
> Finally, we'll need to update the log gathering code in CI to know how
> to look inside lxd containers. At the moment, only the machine log
> seems to be linked into the /var/log/lxd/ directory, so the cloud-init
> logs and other pieces are currently missing. It does seem we can peek
> inside using paths like:
>
>
> /var/lib/lxd/containers/juju-d9c2c426-f268-47d9-8b96-4468b3f60b51-machine-0/rootfs/var/log/apt/term.log
>
> But I'm not sure if that's behaviour we can rely on with all lxd
> configurations.
>
> Martin
>
> --
> 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/20160418/0727e447/attachment-0001.html>