Simon, I've gone ahead and added you as a subscriber to the blueprint
<https://blueprints.launchpad.net/juju-core/+spec/charmer-experience-shared-filesystems>
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
[email protected]
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju
