Latest on the LXD Provider!

[Simon Davy]

On 10 November 2015 at 20:46, Mark Shuttleworth <mark at ubuntu.com> wrote:
> On 10/11/15 11:06, Simon Davy wrote:
>> We've been using lxd with the manual provider, really been impressed
>> with what lxd brings to the table.
>
> Yes, it's a really dramatic leap forward in distributed systems dev and
> test, glad you like it :)
>
>> Couple of questions
>>
>>  - do you have plans to support applying user-defined lxd profiles to
>> the lxd containers that juju creates? This would be great in dev, and
>> in special cases (e.g. give your charm access to the gpu, or bind
>> mount a host dir)
>
> This would map nicely to the generic ideas of machine-type or machine
> constraints, so should be achievable. Why not write up a proposal? We'd
> want it to feel just like choosing a particular machine type on your
> cloud, only in this case you'd be choose a "container machine type".

Yes, does seem to mesh nicely with machine type idea. Your provider
could maintain a set of profiles available for users to choose from.

Some uses cases OTTOMH:

Production:

 - exposing special devices like gpu

 - exposing an encrypted block device to a container that has the keys
to decrypt and mount (although I understand there are security issues
atm with the kernel superblock parser)

 - selecting networking type.  We've had to manually add maas machines
in with regular openstack kvm for high-connection frontends before,
due to kvm networking limitations. I would be great if we could deploy
with lxd and tell it to use the host network (assuming this is
possible in lxd in the future). I guess there'd be some security
compromises here.

 - A more of off-the-wall idea: local volume sharing/publishing, a la
docker, would be very interesting.  It could allow faster/more secure
communication between containers on the same host by using unix
sockets, for example.


Development use cases

- mounting specific code branches into the lxd for development

- mount users $HOME dir for convenience (ssh keys, bash/editor/bzr config, etc)

- controlling the subuid/gid map for the above

- sharing the X socket with the container (useful if you have selenium
tests, for example)

- controlling the network bridge, a la Jay's recent post.

- adding additional veths/bridges, in order to test your charm's
handling of public/private ip addresses (currently only possible by
deploying to an actual cloud provider, AFAIK)

- likewise for volumes - if adding an lxd disk device could link into
the new storage hooks, then we can test our storage hooks locally.

Hmm, maybe some of these are not solved by custom lxd profiles, but
just lxd provider feature requests :)

I would happily write up a proposal - is this list the correct venue?

>>  - likewise, will users be able to specify base lxd image to use?
>
> Actually, we'd like to be able to do that on any cloud, not just on LXD.
> Essentially saying something like:
>
>   juju deploy somecharm --image f67d90bad257
>
> I'm paraphrasing, but the idea is to tell Juju not to lookup the image
> ("trusty", "precise") the way it normally would, but just to trust you
> and wing it with that base image. This wants to be done in a way which
> works for LXD and on any cloud that can provide a named snapshot or
> image for launch.

\o/ - hurrah!  This would be great. We could publish these images out
of our CI process, for our application charms. As well as maybe
consume an IS-provided base image for other services, rather than the
cumbersome basenode scripts we currently use.

Is there a spec document for this?

> For LXD development purposes, this would let you have a base image with
> all the main dependencies you're going to need pre-defined, so the
> actual charm install is super-fast.

Yep, this is kinda what we are doing w/the manual provider and lxd
currently, for application development with juju. We create an lxd
ahead of time and install dependencies. We then bind mount the
developer's code/logs/config directories into the lxd at the places
the charm expects, and then bootstrap and deploy all charms onto that
one container. This gives us a self contained development environment,
using the same tooling as production, but convenient for devs to use.
We've only just got this set up, so early days yet, but it looks
promising.

The more I use LXD, the more excited I get :) I'm trying to retain a
cool, professional, level-headed, right-tool-for-the-job, and
objective persona, but I'm think I'm in danger of becoming a total
fanboy, as I suspect my colleagues will attest to :D

Thanks

-- 
Simon