LXD polish for xenial

[roger peppe]

On 20 April 2016 at 06:41, Marco Ceppi <marco.ceppi at canonical.com> wrote:
> On Tue, Apr 19, 2016 at 11:39 PM John Meinel <john at arbash-meinel.com> wrote:
>>
>> ...
>>
>>>>
>>>> So the plan as I understand it is that we're planning on updating
>>>> Bundles to use the term "lxd" as the container they are requesting. And then
>>>> updating the deployer and other tools to understand that they need to
>>>> translate that back to LXC for Juju-1.X. The rationale is that we don't want
>>>> to be stuck using old terminology forever, and the change is easy to do for
>>>> bundles.
>>>
>>>
>>> My understanding was different. My understanding was that Juju 2.0 was to
>>> understand both lxc and lxd so old bundles work just fine with Juju 2.0. If
>>> you have a bundle with lxd in it, it was clearly written for 2.0 so it's
>>> fine that it doesn't deploy with Juju 1.x.
>>>
>>> Having Juju 2.0 not understand lxc seems silly given that in fact a lxd
>>> container is just an lxc. We seem to be splitting hairs at the cost of
>>> users.
>>>
>>> -Dean
>>
>>
>> So I'd like to clarify a few points here. The first very key point is that
>> the old "lxc" containers are *not* the same as "lxd" containers. It is a bit
>> unfortunate, but I'll go through some reasons:
>>
>> Both of them do use cgroups, etc to create isolation between containers,
>> but so does docker, and I don't think people feel docker containers are
>> interchangable with lxc or lxd containers.
>> There is a package called "lxc" that you can install, which provides the
>> old "lxc-foo" commands (lxc-start, lxc-stop, lxc-launch, etc)
>> There is also a package called "lxdclient" which installs a local binary
>> named "/usr/bin/lxc". That, however, does *not* interact with the former
>> package.
>> Very concretely, if you do "lxc-launch -t ubuntu-cloud" then that
>> container will not show up in "lxc list". "lxc" is the lxdclient and talks
>> to the lxd daemon to get work done. "lxc-*" commands do all of the container
>> creation, etc, themselves.
>> Going forward I'll call the old thing 'lxc1' because that is the new
>> package for it (AIUI). And I'll enumerate some more of the differences
>>
>> lxc1 containers are priviledged by default and require you to be root to
>> create them. lxd containers are unpriviledged by default and can be
>> requested by any user. The daemon itself runs as root to provide the
>> functionality, but the container you get will not have a root-elevation
>> escape mechanism.
>> lxc1 containers download from cloud-images to /var/cache/lxc and populate
>> /var/lxc/* with the rootfs and where the container files themselves are. lxd
>> caches images differently (/var/lib/lxd/images, IIRC) and supports the use
>> of things like ZFS filesystem mounts to provide fast cloning to launch a new
>> image.
>>
>>
>> Juju itself could continue to support its existing logic to create and
>> manage 'lxc' containers as a separate bunch of containers from 'lxd'
>> containers. They would end up on different bridges, have different code
>> paths for creating them (lxd we talk directly to the HTTP REST api of the
>> daemon, 'lxc' we have to exec a command and parse the string output.)
>> We have been directed that we really don't want to be supporting 2 very
>> similar-but-not-the-same container mechanism for the next 5 years, and going
>> to 2.0 is the one time we're going to get to break support for the old
>> mechanism.
>
>
> From the users perspective and from a more simplified view point, lxd
> containers /are/ lxc containers. The user wants a container not a daemon
> (lxd), so in juju 2.0 any bundle that says 'lxc' should get a lxc container
> via lxd in 2.0.
>
> No one is asking that juju support two containers, we're saying juju should
> do the right thing and not poke users in the eye because of a bunch of
> technical, non-user impacting changes that happened in how juju created the
> container.
>
> LXD as a provider makes sense, since we're talking to the /provider/ which
> is that LXD "hypervisor". LXD as a container type does not make as much
> sense, because it's a LXC type container that Juju provisioned through LXD.
> It just happens to be LXC 2.0 and is way better, but to the charm in the
> container and the user requesting it, it's still a LXC machine.
>
> Marco

That makes a lot of sense to me. I have to say that when I was
coming to use lxd with juju for the first time, the difference in meaning
between "lxd" and "lxc" was confusing - I hadn't realised that
the "d" in lxd stood for "daemon" rather than "one more than the
letter 'c'". The fact that the command to manipulate lxd containers
was named "lxc" added to my confusion.