On 16 November 2015 at 17:07, Rick Harding <rick.hard...@canonical.com> 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
