RFC: unmounting /mnt on AWS instances
andrew.wilkins at canonical.com
Tue Nov 18 02:37:18 UTC 2014
On Tue, Nov 18, 2014 at 10:25 AM, Marco Ceppi <marco at ondina.co> wrote:
> I have a few charms that expect /mnt to be the ephemeral disk, while it
> wouldn't be a huge headache and I certainly wouldn't want to stand in the
> way of progress. It won't be trivial and I'll start to devise a way to test
> all the charms so we can get a count of charms that expect /mnt to exist.
> This should be a good starting place for how much effort would be required
> to accommodate this new feature.
Any idea what version of juju we can expect to start seeing this land?
Sorry, I don't have a timeline as of yet. Work has started, but specs and
designs are still subject to change.
The intention is to have it ready by 15.04.
> Marco Ceppi
> On Mon Nov 17 2014 at 9:13:45 PM Andrew Wilkins <
> andrew.wilkins at canonical.com> wrote:
>> Hi all,
>> I am working on introducing storage as a first-class primitive in Juju.
>> Charms will be able to indicate that they require storage (block devices,
>> filesystems...), and when you deploy that charm you will be able to specify
>> some parameters in order to fulfil the storage requirement.
>> One thing I'd like to do is provide users a means of assigning ephemeral
>> disks to units. The AMIs we use on AWS currently auto-mount the first
>> ephemeral disk (if there is one) at /mnt. I think Azure does something
>> similar; not sure about other providers.
>> Are you relying on /mnt being there? If so, would it cause you a headache
>> if this were taken away, by performing a "umount /mnt" after booting? (Bear
>> in mind you can still mount it afterwards if you want to).
>> Juju mailing list
>> Juju at lists.ubuntu.com
>> Modify settings or unsubscribe at: https://lists.ubuntu.com/
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Juju