Thanks for the update, appreciate the consideration! On Sat, Apr 23, 2016, 2:29 PM Alexis Bruemmer <[email protected]> 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 <[email protected]> > wrote: > >> On Tue, Apr 19, 2016 at 10:39 PM, John Meinel <[email protected]> >> 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 >> [email protected] >> Modify settings or unsubscribe at: >> https://lists.ubuntu.com/mailman/listinfo/juju-dev >> >> > > > -- > Alexis Bruemmer > Juju Core Manager, Canonical Ltd. > (503) 686-5018 > [email protected] > -- > Juju-dev mailing list > [email protected] > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/juju-dev >
-- Juju-dev mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
