<div dir="ltr">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:<div><br></div><div>(1) Juju 2.0 will manage containers with LXD exclusively</div><div>(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</div><div>(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.</div><div><br></div><div>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.</div><div><br></div><div>Please continue to provide the team with great feedback and let us know if you have questions or concerns.</div><div><br></div><div>Alexis<br><div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Apr 21, 2016 at 8:00 AM, Dean Henrichsmeyer <span dir="ltr"><<a href="mailto:dean@canonical.com" target="_blank">dean@canonical.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span><div class="gmail_extra"><div class="gmail_quote">On Tue, Apr 19, 2016 at 10:39 PM, John Meinel <span dir="ltr"><<a href="mailto:john@arbash-meinel.com" target="_blank">john@arbash-meinel.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>...</div><span><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span><div></div></span><div>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.</div></div></div></div></blockquote><div></div></div><br></div></span><div class="gmail_extra">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.</div><div class="gmail_extra"><br></div><div class="gmail_extra">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.</div><span><font color="#888888"><div class="gmail_extra"><br></div><div class="gmail_extra">-Dean</div></font></span></div></blockquote><div><br></div></span><div>So I'd like to clarify a few points here. The first <i>very</i> 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:</div><div><ol><li>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.</li><li>There is a package called "lxc" that you can install, which provides the old "lxc-foo" commands (lxc-start, lxc-stop, lxc-launch, etc)</li><li>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.</li><li>Very concretely, if you do "lxc-launch -t ubuntu-cloud" then that container will <b>not</b> 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.</li><li>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</li><ol><li>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.</li><li>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.</li></ol></ol><div><br></div></div><div>Juju itself <b>could</b> 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.)</div><div>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.</div></div></div></div></blockquote><div></div></div><br></div></span><div class="gmail_extra">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?</div><div class="gmail_extra"><br></div><div class="gmail_extra">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.</div><span><font color="#888888"><div class="gmail_extra"><br></div><div class="gmail_extra">-Dean</div></font></span></div>
<br>--<br>
Juju-dev mailing list<br>
<a href="mailto:Juju-dev@lists.ubuntu.com" target="_blank">Juju-dev@lists.ubuntu.com</a><br>
Modify settings or unsubscribe at: <a href="https://lists.ubuntu.com/mailman/listinfo/juju-dev" rel="noreferrer" target="_blank">https://lists.ubuntu.com/mailman/listinfo/juju-dev</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div><div dir="ltr">Alexis Bruemmer<div>Juju Core Manager, Canonical Ltd.</div><div><a href="tel:%28503%29%20686-5018" value="+15036865018" target="_blank">(503) 686-5018</a></div><div><a href="mailto:alexis.bruemmer@canonical.com" target="_blank">alexis.bruemmer@canonical.com</a></div></div></div>
</div></div></div></div>