RFC: unmounting /mnt on AWS instances
andrew.wilkins at canonical.com
Wed Nov 19 05:15:39 UTC 2014
On Wed, Nov 19, 2014 at 1:07 PM, Stuart Bishop <stuart.bishop at canonical.com>
> On 19 November 2014 09:50, Andrew Wilkins <andrew.wilkins at canonical.com>
> > Ideally that would not be "/mnt", because otherwise we're going to end up
> > with a lot of charms that cannot be co-located. My point is that it can
> > /mnt, and your charm will keep working without any changes to hooks.
> Somewhat off topic, but I was discussing this just the other day. A
> lot of charms specify a mount point in their configuration, and the
> only rationale me and other admins could come up with for allowing
> this to be configurable is co-location. However, that is somewhat
> broken too since you still can't co-locate multiple units in the same
> container (because the mountpoint is service configuration, and shared
> between all the units). So the sane way is to drop the mountpoint
> configuration option, and just hard code the charms to pass
> /srv/$service_$unitnum as the mountpoint they pass to the block
> storage broker.
Agreed. The mount point location will be optional, in which case Juju will
assign a unique one. I think this will/should be the recommendation to
> fwiw, if we needed a charm and discovered it used /mnt, we would
> probably 'fix' it to use /srv/whatever. I certainly wouldn't want my
> service to fail because someone plugged a USB drive into the MaaS
> deployed hardware.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Juju