Open Stack

Excerpts from Greg Poirier's message of 2013-08-10 22:11:06 -0700:
> Since we can't guarantee that a volume, when attached, will become a
> specified device name, we would like to be able to create a filesystem and
> label it (so that we can programmatically interact with it when
> provisioning systems, services, etc).
> 
> What we are trying to decide is whether this should be the responsibility
> of Nova or Cinder. Since Cinder essentially has all of the information
> about the volume and is already responsible for creating the volume
> (against the configured backend), why not also give it the ability to mount
> the volume (assuming support for it on the backend exists), run
> mkfs.<filesystem_type>, and then use tune2fs to label the volume with (for
> example) the volume's UUID?

Like others, I am a little dubious about adding a filesystem to these
disks for a number of reasons. It feels like a violation of "its just
a bunch of bits".

Have you considered putting a GPT on it instead?

With a GPT you have a UUID for the disk which you can communicate to the
host via metadata service. With that you can instruct gdisk to partition
the right disk programattically and create the filesystem with native
in-instance tools.

This is pure meta-data, and defines a lot less than a filesystem, so it
feels like a bigger win for the general purpose case of volumes.  It will
work for any OS that supports GPT, which is likely _every_ modern PC OS.