On Wed, Nov 19, 2014 at 1:07 PM, Stuart Bishop <stuart.bis...@canonical.com> wrote:
> On 19 November 2014 09:50, Andrew Wilkins <andrew.wilk...@canonical.com> > wrote: > > > 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 > be > > /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 charm authors. > 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. >
-- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju