Open Stack

On Tue, Aug 13, 2013 at 1:37 PM, Caitlin Bestler <
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130813/9f266e48/attachment.html>