Open Stack

On 8/13/2013 11:42 PM, Greg Poirier wrote:
> On Tue, Aug 13, 2013 at 1:37 PM, Caitlin Bestler
> <caitlin.bestler at nexenta.com <mailto:caitlin.bestler at nexenta.com>> wrote:
>
>     I'm not following something here. What is the point at dictating a
>     specific FS format when the compute node will be the one applying
>     the interpretation?
>
>
> This is the rabbithole that made me start to re-think our approach.
>
> Our goal is to make it so that developers can self-service provision
> additional storage for themselves, grow filesystems, etc without having
> to ... well... know how. There are so many approaches to this (within
> the Openstack community) that we thought "why not just make this
> something that Cinder can do?"
>
>     Isn't a 120 GB volume which the VM will interpret as an EXT4 FS just
>     a 120 GB volume that has a *hint* attached to it?
>
>
> Yes, in the same sense that a 120 GB volume is just a starting point on
> a disk with a hint attached to it.
>
>     And would there be any reason to constrain in advance the set of hints
>     that could be offered?
>
>
> Simplicity.
>
> I think that what would make this idea tractable would be to abstract
> away the filesystem-level stuff into an abstract factory that Cinder
> would use. Each FS type would implement the factory accordingly and
> register itself somehow with Cinder. So Cinder operators would have a
> range of choices for making filesystems available to users.
>
> Of course, that's anything but simple, right?
>
> What we really want (and are comfortable working with) is predictability
> and consistency.
>
> Currently, if I specify a device name via nova volume-attach, we can end
> up in a state where our metadata regarding the attachment is incorrect.
> E.g. a device is attached as /dev/vdb, but I specified /dev/vdc and the
> attachment's 'device' parameter says /dev/vdc.
>
> We have the alternative of using the truncated
> /dev/disk/by-id/virtio-<truncated uuid> to find the attached volume, but
> you cannot guarantee that there will not be a collision in an
> environment with a sufficient number of volumes.
>
> I'd be personally satisfied if that weren't truncated and would move
> along. It's something else I'm looking into.
>

Having factory classes sounds like a great way to make this both 
extensible and error free. But it still only requires the Cinder Volume 
driver to echo a tag given to it, with no need to validate or understand it.