Re: RFC: unmounting /mnt on AWS instances
On 18 November 2014 09:25, Marco Ceppi ma...@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. Would any charm that expected this work on other providers like OpenStack? If so then relying on this, rather than using tools like the block storage broker or old-skool explicit manual mounting, could be considered a bug for the test runners to pick up. -- Stuart Bishop stuart.bis...@canonical.com -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: RFC: unmounting /mnt on AWS instances
On Tue, Nov 18, 2014 at 10:58 PM, David Britton david.brit...@canonical.com wrote: On Mon, Nov 17, 2014 at 8:25 PM, Marco Ceppi ma...@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 I'm in the same boat, it won't be a huge headache, but it will be work to do. I've always thought that putting the ephemeral on /mnt was a bit of an odd decision, but it's not a killer. Some things I've thought of: If you leave things the way they are, you can still use /mnt as it is. The ephemeral survives reboots, so any persistent dirs put in there would be fine and work seamlessly to the user. Also if people wanted to continue to write out larger files to /mnt, that would work fine as well. If you remove the behavior, it would be good to have it on /mnt/juju-ephemeral-0 or something like that. The way things are intended to work (subject to change), is that Juju will periodically list disks and whether or not they are in use (mounted). If they're not in use, then the Juju user can assign the disk to a unit that wants storage. So it's not a problem that it's in /mnt, but a matter of whether we can not mount it at all. We'll also enable requesting/assigning disks at instance provisioning time, and dynamically post-provisioning. In terms of changing charms, I think at worst you'd have to add something like this to your charm metadata: storage: arbitraryname: type: filesystem location: /mnt required: true Then when you deploy to AWS, you should be able to do this: $ juju deploy mycharm --storage arbitraryname=ephemeral0 or $ juju deploy mycharm --storage arbitraryname=100G,iops:1 or ... 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. Cheers, Andrew -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: RFC: unmounting /mnt on AWS instances
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. 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 stuart.bis...@canonical.com -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: RFC: unmounting /mnt on AWS instances
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
Re: RFC: unmounting /mnt on AWS instances
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? Thanks! Marco Ceppi On Mon Nov 17 2014 at 9:13:45 PM Andrew Wilkins andrew.wilk...@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). Cheers, Andrew -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/ mailman/listinfo/juju -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: RFC: unmounting /mnt on AWS instances
On Tue, Nov 18, 2014 at 10:25 AM, Marco Ceppi ma...@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. Thanks! 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. Cheers, Andrew Thanks! Marco Ceppi On Mon Nov 17 2014 at 9:13:45 PM Andrew Wilkins andrew.wilk...@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). Cheers, Andrew -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/ mailman/listinfo/juju -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: RFC: unmounting /mnt on AWS instances
+smoser On Mon, Nov 17, 2014 at 8:13 PM, Andrew Wilkins andrew.wilk...@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). Cheers, Andrew -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
