Re: Latest on the LXD Provider!

[Simon Davy]

On 18 November 2015 at 17:15, Katherine Cox-Buday
 wrote:
> Simon, I've gone ahead and added you as a subscriber to the blueprint for
> this feature. That was as things develop you can stay in the loop.
>
> Would you be willing to give feedback on how this feature is shaping up when
> we begin developing?

Absolutely.

I spend 80% of my working day using the current local provider, so am
keen to help improve things.

We are also trying to use juju in application development, i.e. have
the deployed charm be the development environment. Currently manually
creating/configuring an lxd container, and deploying the charm to it
with the manual provider. I would be keen to see what options might be
possible to do this with the lxd provider, like providing a base
image, and configuring the container with profiles, as we could then
use the lxd provider to create the units rather than manually.

Thanks

-- 
Simon

-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Latest on the LXD Provider!

[Katherine Cox-Buday]

Simon, I've gone ahead and added you as a subscriber to the blueprint 
 
for this feature. That was as things develop you can stay in the loop.


Would you be willing to give feedback on how this feature is shaping up 
when we begin developing?


-
Katherine

On 11/16/2015 11:07 AM, Rick Harding wrote:

On Mon, 16 Nov 2015, Simon Davy wrote:


Some uses cases OTTOMH:

- mounting specific code branches into the lxd for development

This is a feature we're looking at Juju adding to support sharing the local
filesystem to the unit deployed with lxd in order to speed up development
cycles. There's a current spec on this that's under iteration and requires
the LXD work to land before it can begin. It'll build on top of the storage
work so that it's meant to be modeled as sharing generic filesystems in all
of the supported providers.


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

Kind of the same as above I'd think. Maybe there's some magic bits to this
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 :)

Yes, as the provider lands I think there'll be room to make sure it gets
first class support for Juju modeling of things such as storage and
networking.



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

Preferably a google doc that folks can comment, question, and refer back
to.



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?

It's a more recent add to the roadmap and we're investigating what it would
take to support this. I'll make sure the team adds you in as a feature
buddy and gets you a copy of the doc as it comes together.

Thanks for the feedback! It's great to see folks excited to use things and
to find guinea pigs as things land and become available.

--
Rick Harding



-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Latest on the LXD Provider!

[Simon Davy]

On 16 November 2015 at 17:07, Rick Harding  wrote:
> On Mon, 16 Nov 2015, Simon Davy wrote:
>
>> Some uses cases OTTOMH:
>>
>> - mounting specific code branches into the lxd for development
>
> This is a feature we're looking at Juju adding to support sharing the local
> filesystem to the unit deployed with lxd in order to speed up development
> cycles. There's a current spec on this that's under iteration and requires
> the LXD work to land before it can begin. It'll build on top of the storage
> work so that it's meant to be modeled as sharing generic filesystems in all
> of the supported providers.

Right. So this could work nicely for the our dev scenario I think, if
we can expose each directory we're interesting as a juju-aware storage
config, which would probably make sense to do anyway, even if we don't
(yet) use it in production.

The tricky part to this for us was matching uids/gids on the the files
system. We ended up setting security.privileged=true as the easiest
path, it be great we can massage the subuid/gids and the id_map to
only map the running user though, rather than throw away uid mapping
altogether.

>> - mount users $HOME dir for convenience (ssh keys, bash/editor/bzr config, 
>> etc)
>
> Kind of the same as above I'd think. Maybe there's some magic bits to this
> example.

Yeah, there's some tricks to mapping the user through to the
container, if you want the full convenience of being able to log in as
host $USER. You need to create the user with the right uid, and also
install that user's shell if it's not the default, etc. Basically, all
the stuff that the old lxc ubuntu template did to support the -b
option.

It might very well be easier for the user to do this customisation in
the base image before deploying, perhaps.

>> - 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 :)
>
> Yes, as the provider lands I think there'll be room to make sure it gets
> first class support for Juju modeling of things such as storage and
> networking.
>
>
>> I would happily write up a proposal - is this list the correct venue?
>
> Preferably a google doc that folks can comment, question, and refer back
> to.
>
>
>> > 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?
>
> It's a more recent add to the roadmap and we're investigating what it would
> take to support this. I'll make sure the team adds you in as a feature
> buddy and gets you a copy of the doc as it comes together.

Yes please!

> Thanks for the feedback! It's great to see folks excited to use things and
> to find guinea pigs as things land and become available.

/me puts on guinea pig costume

Thanks!

-- 
Simon

-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Latest on the LXD Provider!

[Rick Harding]

On Mon, 16 Nov 2015, Simon Davy wrote:

> Some uses cases OTTOMH:
>
> - mounting specific code branches into the lxd for development

This is a feature we're looking at Juju adding to support sharing the local
filesystem to the unit deployed with lxd in order to speed up development
cycles. There's a current spec on this that's under iteration and requires
the LXD work to land before it can begin. It'll build on top of the storage
work so that it's meant to be modeled as sharing generic filesystems in all
of the supported providers.

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

Kind of the same as above I'd think. Maybe there's some magic bits to this
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 :)

Yes, as the provider lands I think there'll be room to make sure it gets
first class support for Juju modeling of things such as storage and
networking.


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

Preferably a google doc that folks can comment, question, and refer back
to.


> > 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?

It's a more recent add to the roadmap and we're investigating what it would
take to support this. I'll make sure the team adds you in as a feature
buddy and gets you a copy of the doc as it comes together.

Thanks for the feedback! It's great to see folks excited to use things and
to find guinea pigs as things land and become available.

--
Rick Harding

-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Latest on the LXD Provider!

[Simon Davy]

On 10 November 2015 at 20:46, Mark Shuttleworth  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

-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Latest on the LXD Provider!

[Simon Davy]

On 9 November 2015 at 18:19, Rick Harding  wrote:
> Thanks Katherine. That's looking great. One request, next demo I'd be
> curious to see how easy it is to run multiple lxd environments locally. I
> know it's been possible with lxc before with a bunch of config.

Just an FYI, I have a tool to manage multiple local provider environments.

https://github.com/bloodearnest/plugins/blob/juju-add-local-env/juju-add-local-env

I've have ~12 local environments that I switch between for my
day-to-day work, usually 3-4 bootstrapped at once. I couldn't work
effectively without multiple environments.

Hopefully the above utility will be made obsolete by the lxd provider,
but it might be useful in the mean time.

> Ideally we'd
> just be able to create a new named section and say it's lxd and boom, I can
> bootstrap the new one and have it distinct from the first.

Yes!  I hope we'll be able to have 1 lxd container running a
multi-environment state server, that can manage multiple lxd
environments on your host (or remotely?)! That would be a great dev
experience.

> Keep up the great work!

And it is indeed great work :)

We've been using lxd with the manual provider, really been impressed
with what lxd brings to the table.

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)

 - likewise, will users be able to specify base lxd image to use?

Many thanks for this work, it has the potential to really benefit our
daily usage of juju.

Thanks



-- 
Simon

-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Latest on the LXD Provider!

[Rick Harding]

Thanks Katherine. That's looking great. One request, next demo I'd be
curious to see how easy it is to run multiple lxd environments locally. I
know it's been possible with lxc before with a bunch of config. Ideally
we'd just be able to create a new named section and say it's lxd and boom,
I can bootstrap the new one and have it distinct from the first.

Keep up the great work!

On Mon, Nov 9, 2015 at 11:59 AM Katherine Cox-Buday <
katherine.cox-bu...@canonical.com> wrote:

> Hey all,
>
> Moonstone spent last iteration tightening up the LXD provider. You can see
> the latest results in our latest Demo Day
> . It's a ~9 minute video
> which demonstrates:
>
>1. The format of the entry into environments.yaml.
>2. LXD bootstrapping locally.
>3. The fact that it's no longer necessary to tweak permissions of the
>unix socket to utilize this.
>4. Juju LXD coming back up when the host is rebooted.
>
> We're also very happy to announce that this will land in the upcoming
> 1.26-alpha2 milestone on 2015-11-17! If you'd like to play with this in the
> meantime, feel free to build from our feature branch
>  and log bugs against the
> blueprint
> .
> Documentation and release notes will be forthcoming.
>
> Thanks, and have fun!
>
> -
> Katherine
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Latest on the LXD Provider!

[Katherine Cox-Buday]

Hey all,

Moonstone spent last iteration tightening up the LXD provider. You can 
see the latest results in our latest Demo Day 
. It's a ~9 minute video 
which demonstrates:


1. The format of the entry into environments.yaml.
2. LXD bootstrapping locally.
3. The fact that it's no longer necessary to tweak permissions of the
   unix socket to utilize this.
4. Juju LXD coming back up when the host is rebooted.

We're also very happy to announce that this will land in the upcoming 
1.26-alpha2 milestone on 2015-11-17! If you'd like to play with this in 
the meantime, feel free to build from our feature branch 
 and log bugs against 
the blueprint 
. 
Documentation and release notes will be forthcoming.


Thanks, and have fun!

-
Katherine

-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Latest on the LXD Provider!

[Sebastian]

Wow! awesome!! \o/

thanks for the info.

Em seg, 9 de nov de 2015 às 17:54, Rick Harding 
escreveu:

> Thanks for the blog post. Great stuff Wayne. I was curious about this
> myself. I should have thought of the limits but hadn't.
>
> On Mon, Nov 9, 2015 at 2:15 PM Katherine Cox-Buday <
> katherine.cox-bu...@canonical.com> wrote:
>
>> Thanks, Rick. We can definitely try out multiple environments locally.
>>
>> I forgot to mention, Wayne did a great blog post
>>  discussing
>> using the LXD provider on remote hosts.
>>
>>
>> On 11/09/2015 12:19 PM, Rick Harding wrote:
>>
>> Thanks Katherine. That's looking great. One request, next demo I'd be
>> curious to see how easy it is to run multiple lxd environments locally. I
>> know it's been possible with lxc before with a bunch of config. Ideally
>> we'd just be able to create a new named section and say it's lxd and boom,
>> I can bootstrap the new one and have it distinct from the first.
>>
>> Keep up the great work!
>>
>> On Mon, Nov 9, 2015 at 11:59 AM Katherine Cox-Buday <
>> katherine.cox-bu...@canonical.com> wrote:
>>
>>> Hey all,
>>>
>>> Moonstone spent last iteration tightening up the LXD provider. You can
>>> see the latest results in our latest Demo Day
>>> . It's a ~9 minute video
>>> which demonstrates:
>>>
>>>1. The format of the entry into environments.yaml.
>>>2. LXD bootstrapping locally.
>>>3. The fact that it's no longer necessary to tweak permissions of
>>>the unix socket to utilize this.
>>>4. Juju LXD coming back up when the host is rebooted.
>>>
>>> We're also very happy to announce that this will land in the upcoming
>>> 1.26-alpha2 milestone on 2015-11-17! If you'd like to play with this in the
>>> meantime, feel free to build from our feature branch
>>>  and log bugs against
>>> the blueprint
>>> .
>>> Documentation and release notes will be forthcoming.
>>>
>>> Thanks, and have fun!
>>>
>>> -
>>> Katherine
>>>
>>
>> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Latest on the LXD Provider!

[Katherine Cox-Buday]

Thanks, Rick. We can definitely try out multiple environments locally.

I forgot to mention, Wayne did a great blog post 
 discussing 
using the LXD provider on remote hosts.


On 11/09/2015 12:19 PM, Rick Harding wrote:
Thanks Katherine. That's looking great. One request, next demo I'd be 
curious to see how easy it is to run multiple lxd environments 
locally. I know it's been possible with lxc before with a bunch of 
config. Ideally we'd just be able to create a new named section and 
say it's lxd and boom, I can bootstrap the new one and have it 
distinct from the first.


Keep up the great work!

On Mon, Nov 9, 2015 at 11:59 AM Katherine Cox-Buday 
> wrote:


Hey all,

Moonstone spent last iteration tightening up the LXD provider. You
can see the latest results in our latest Demo Day
. It's a ~9 minute
video which demonstrates:

 1. The format of the entry into environments.yaml.
 2. LXD bootstrapping locally.
 3. The fact that it's no longer necessary to tweak permissions of
the unix socket to utilize this.
 4. Juju LXD coming back up when the host is rebooted.

We're also very happy to announce that this will land in the
upcoming 1.26-alpha2 milestone on 2015-11-17! If you'd like to
play with this in the meantime, feel free to build from our
feature branch 
and log bugs against the blueprint

.
Documentation and release notes will be forthcoming.

Thanks, and have fun!

-
Katherine



-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Latest on the LXD Provider!

[Rick Harding]

Thanks for the blog post. Great stuff Wayne. I was curious about this
myself. I should have thought of the limits but hadn't.

On Mon, Nov 9, 2015 at 2:15 PM Katherine Cox-Buday <
katherine.cox-bu...@canonical.com> wrote:

> Thanks, Rick. We can definitely try out multiple environments locally.
>
> I forgot to mention, Wayne did a great blog post
>  discussing
> using the LXD provider on remote hosts.
>
>
> On 11/09/2015 12:19 PM, Rick Harding wrote:
>
> Thanks Katherine. That's looking great. One request, next demo I'd be
> curious to see how easy it is to run multiple lxd environments locally. I
> know it's been possible with lxc before with a bunch of config. Ideally
> we'd just be able to create a new named section and say it's lxd and boom,
> I can bootstrap the new one and have it distinct from the first.
>
> Keep up the great work!
>
> On Mon, Nov 9, 2015 at 11:59 AM Katherine Cox-Buday <
> katherine.cox-bu...@canonical.com> wrote:
>
>> Hey all,
>>
>> Moonstone spent last iteration tightening up the LXD provider. You can
>> see the latest results in our latest Demo Day
>> . It's a ~9 minute video
>> which demonstrates:
>>
>>1. The format of the entry into environments.yaml.
>>2. LXD bootstrapping locally.
>>3. The fact that it's no longer necessary to tweak permissions of the
>>unix socket to utilize this.
>>4. Juju LXD coming back up when the host is rebooted.
>>
>> We're also very happy to announce that this will land in the upcoming
>> 1.26-alpha2 milestone on 2015-11-17! If you'd like to play with this in the
>> meantime, feel free to build from our feature branch
>>  and log bugs against
>> the blueprint
>> .
>> Documentation and release notes will be forthcoming.
>>
>> Thanks, and have fun!
>>
>> -
>> Katherine
>>
>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju