On 19 November 2014 09:50, Andrew Wilkins <[email protected]> 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. 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. -- Stuart Bishop <[email protected]> -- Juju mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
