<div dir="ltr"><div><div>Hi,<br><br></div>Why not use the REST api?<br><br></div>chuck<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, May 10, 2015 at 7:03 PM, Tim Penhey <span dir="ltr"><<a href="mailto:tim.penhey@canonical.com" target="_blank">tim.penhey@canonical.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi folks,<br>
<br>
I am looking into creating a new provider for Juju based on lxd.<br>
<br>
The current local provider uses lxc by default, and kvm with an option.<br>
Some creative types actually figured out how to create a mixed container<br>
local provider environment that was never intended to work, but it did.<br>
<br>
There are two key behaviours that the current Juju local provider has<br>
that I'd like to avoid with the new lxd provider:<br>
 * requires sudo to bootstrap the environment<br>
 * has the host as machine-0, and is the only machine that can create<br>
containers, which means the local provider cannot be used to test HA<br>
<br>
So... for the real basic behaviour, what I need to be able to do is to<br>
create containers and pass it cloud-init data.  The true basics are:<br>
create, start, stop, destroy, list.<br>
<br>
Since lxd and Juju are both written in Go, I was wondering the best way<br>
to integrate.  For the existing lxc commands, Juju effectively shells<br>
out to execute lxc-ls, lxc-create etc.<br>
<br>
Juju would like to take advantage of fast cloning of containers, but<br>
from reading the docs, it isn't entirely clear to me the best way to do<br>
this.<br>
<br>
I did read somewhere that lxd has plans to drive other container types<br>
as well. How far down the track is that? I am thinking primarily around<br>
the ability for the lxd provider to support a mixed container approach<br>
to support the use cases of the people that do this with the local<br>
provider, but in a more defined and expected way.<br>
<br>
We'd also like the lxd provider to be considered first class. By this I<br>
mean that people could use the lxd provider for production deployments,<br>
something that we don't recommend for the local provider (even though I<br>
know of at least one).<br>
<br>
Obviously there are many nifty features that Juju would like to support<br>
that lxd either currently has or has plans for, but working out how best<br>
to work that support into Juju is likely to be challenging.  A key one<br>
here is mounting directories from the host into the container to make<br>
charm development easier.<br>
<br>
Another is an easy way to add port mapping to the host to handle<br>
exposing services that are perhaps only on an internal IP address, but<br>
we'd like the host to map that port on its own ip address into the<br>
container.  I'm not sure if this is something that lxd is looking to<br>
provide or not.<br>
<br>
Questions or comments very welcome.  The development of the lxd provider<br>
is a part time task for me, but something that I, and other core people<br>
are wanting to work on ASAP - mostly as Friday afternoon tasks for now.<br>
<br>
Cheers,<br>
Tim<br>
_______________________________________________<br>
lxc-users mailing list<br>
<a href="mailto:lxc-users@lists.linuxcontainers.org">lxc-users@lists.linuxcontainers.org</a><br>
<a href="http://lists.linuxcontainers.org/listinfo/lxc-users" target="_blank">http://lists.linuxcontainers.org/listinfo/lxc-users</a></blockquote></div><br></div>