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

[Tim Penhey]

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