[lxc-users] Determining the best way for Juju to interact with lxd

[Chuck Short]

Hi,

Why not use the REST api?

chuck

On Sun, May 10, 2015 at 7:03 PM, Tim Penhey <tim.penhey at canonical.com>
wrote:

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