Open Stack

It may make the dependency tree a bit weird but Cinder could use Nova to do the actual work. Make a bare minimum image that Cinder fires up under Nova, attaches the volumes, and then does the partitioning/formatting. Once setup, the vm can be terminated. This has the benefit of reusing a lot of code in Cinder and Nova. It also would provide a lot of protection from dangerous code like formatting from being able to see disks not intended to be formatted. The API would live under Cinder as the Nova stuff would simply be an implementation detail the user need not know about.

Thanks,
Kevin


________________________________________
From: Greg Poirier [greg.poirier at opower.com]
Sent: Monday, August 12, 2013 9:37 AM
To: OpenStack Development Mailing List
Subject: Re: [openstack-dev] Extension to volume creation (filesystem and       label)

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

On Mon, Aug 12, 2013 at 9:15 AM, Vishvananda Ishaya <vishvananda at gmail.com<mailto: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.