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

[Tim Penhey]

It is definitely an option. I was wanting to ask if it was the best
option.  It seems that the lxc CLI tool already wraps the REST api with
a Go client.  I was thinking Juju could use that rather than the raw
REST. I don't see why we should wrap it too.

Also, the REST api is defined to be unstable at this stage, and I'd like
to avoid instability as much as possible, although it seems that there
would be exactly the same problems with api instability which ever way
we choose to consume lxd.

Tim

On 11/05/15 11:33, Chuck Short wrote:
> Hi,
> 
> Why not use the REST api?
> 
> chuck
> 
> On Sun, May 10, 2015 at 7:03 PM, Tim Penhey <tim.penhey at canonical.com
> <mailto: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
>     <mailto:lxc-users at lists.linuxcontainers.org>
>     http://lists.linuxcontainers.org/listinfo/lxc-users
> 
> 
> 
> 
> _______________________________________________
> lxc-users mailing list
> lxc-users at lists.linuxcontainers.org
> http://lists.linuxcontainers.org/listinfo/lxc-users
>