Open Stack

On Mon, Aug 12, 2013 at 9:18 AM, John Griffith
<john.griffith at solidfire.com>wrote:

>
> On Mon, Aug 12, 2013 at 9:15 AM, Vishvananda Ishaya <vishvananda at gmail.com
> > wrote:
>
>> This would need to happen on the cinder side on creation. I don't think
>> it is safe for nova to be modifying the contents of the volume on attach.
>> That said nova does currently set the serial number on attach (for libvirt
>> at least) so the volume will show up as:
>>
>> /dev/disk/by-id/virtio-<uuid>
>>
>> Although the uuid gets truncated.
>>
>> Vish
>
>
I missed this in my first passthrough. Thanks for pointing that out.

We still like the idea of creating the filesystem (to make block storage
truly self-service for developers), but we might be able to work around
that. It seems that my initial feeling that this would be dealt with in
Cinder was correct, though.


> The virtio-<uuid> method Vish described has worked pretty well for me so
> hopefully that will work for you.  I also don't like the idea of doing a
> parition/format on attach in compute, seems like an easy path to
> inadvertently loosing your data.
>

We could track the state of the filesystem somewhere in the Cinder model.
Only try to initialize it once.

If you still want to look at adding the partition/format functionality to
> Cinder it's an interesting idea, but to be honest I've discounted it in the
> past because it just seemed "safer" and more flexible to leave it to the
> instance rather than trying to cover all of the possible partition schemes
> and FS types etc.
>

Oh, we don't want to get super fancy with it. We would probably only
support one filesystem type and not partitions. E.g. You request a 120GB
volume and you get a 120GB Ext4 FS mountable by label.

It may potentially not be worth the effort, ultimately. We'll have to
continue our discussions internally... particularly since now I know where
a useful identifier for the volume is under the dev fs.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130812/fe407af9/attachment.html>