LXD polish for xenial

Sat Apr 23 19:45:42 UTC 2016

Thanks for the update, appreciate the consideration!

On Sat, Apr 23, 2016, 2:29 PM Alexis Bruemmer <alexis.bruemmer at canonical.com>
wrote:

> Thank you all for the great feedback on 2.0! Based on this thread and
> similar feedback the juju-core dev team has made some updates to the plan
> for lxd support in juju 2.0.  Most notably on how juju 2.0 will handle
> bundles specifying use of containers.  A summary of container support for
> juju 2.0:
>
> (1) Juju 2.0 will manage containers with LXD exclusively
> (2) On the command line the user will need to specify "--to lxd"; Juju 2.0
> will provide a clear error message if "--to lxc" is used
> (3) For bundles, Juju 2.0 will retain backwards compatibility by accepting
> the name of "lxc" and "lxd" to mean "you want a container managed by lxd",
> this will allow yaml files written for juju 1.x to be used for juju 2.0
> without requiring updates.  There will be a clear message post deployment
> that lets the user know lxd was used to deploy and manage containers and
> that the yaml file should be updated.  We will retain this backwards
> compatibility for the life of 2.0.
>
> Please also note that the current beta versions of Juju still has the
> previous lxc support (along side the lxd) to allow for proper test coverage
> of Juju 2.0 while the lxd "kinks" are worked through.  When the team is
> satisfied with test coverage of LXD on juju 2.0 we will remove the previous
> lxc implementation.
>
> Please continue to provide the team with great feedback and let us know if
> you have questions or concerns.
>
> Alexis
>
> On Thu, Apr 21, 2016 at 8:00 AM, Dean Henrichsmeyer <dean at canonical.com>
> wrote:
>
>> On Tue, Apr 19, 2016 at 10: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.
>>>
>>
>> OK, there's confusion. When I say supporting 'lxc' in bundles, I mean
>> literally supporting the word 'lxc' - not actually supporting traditional
>> LXC containers. If Juju 2.0 sees 'lxc' in a bundle, it will use LXD
>> containers for those targets. In the case of bundles and Juju 2.0, the word
>> 'lxc' and 'lxd' will be interchangeable in order to allow for backwards
>> compatibility. Juju 2.0 won't support both LXC and LXD containers. Does
>> that make more sense?
>>
>> That simply allows for having bundles that work with both Juju 1 and Juju
>> 2 and does NOT require Juju 2.0 to support traditional LXC containers.
>>
>> -Dean
>>
>> --
>> Juju-dev mailing list
>> Juju-dev at lists.ubuntu.com
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>>
>>
>
>
> --
> Alexis Bruemmer
> Juju Core Manager, Canonical Ltd.
> (503) 686-5018
> alexis.bruemmer at canonical.com
> --
> 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/20160423/eac4feb3/attachment-0001.html>