LXD polish for xenial

[Marco Ceppi]

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:
>
>    1. 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.
>    2. There is a package called "lxc" that you can install, which
>    provides the old "lxc-foo" commands (lxc-start, lxc-stop, lxc-launch, etc)
>    3. 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.
>    4. 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.
>    5. 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
>       1. 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.
>       2. 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20160420/6c7d7bdd/attachment-0001.html>