Open Stack

Hi,

Some days ago, a bunch of Nova specs were approved for Kilo.  Among them
was https://blueprints.launchpad.net/nova/+spec/use-libvirt-storage-pools

Now, while I do recognize the wisdom of using storage pools, I do see a
couple of possible problems with this, especially in the light of my
upcoming spec proposal for using StorPool distributed storage for the VM
images.

My main concern is with the explicit specification that the libvirt pools
should be of the "directory" type, meaning that all the images should be
visible as files in a single directory.  Would it be possible to extend the
specification to allow other libvirt pool types, or to allow other ways of
pointing Nova at the filesystem path of the VM image?

Where this is coming from is that StorPool volumes (which we intend to
write a DiskImage subclass for) appear in the host filesystem as
/dev/storpool/volumename special files (block devices).  Thus, it would
be... interesting... to find ways to make them show up under a specific
directory (yes, we could do lots and lots of symlink magic, but we've been
down that road before and it doesn't necessarily lead to Good Things(tm)).
I see that the spec has several mentions of "yeah, we should special-case
Ceph/RBD here, since they do things in a different way" - well, StorPool
does things in a slightly different way, too :)

And yes, we do have work in progress to expose the StorPool cluster's
volumes as a libvirt pool, but this might take a bit of time to complete
and then it will most probably take much more time to get into the libvirt
upstream *and* into the downstream distributions, so IMHO "okay, let's use
different libvirt pool types" might not be entirely enough for us, although
it would be a possible workaround.

Of course, it's entirely possible that I have not completely understood the
proposed mechanism; I do see some RBD patches in the previous incarnations
of this blueprint, and if I read them right, it *might* be trivial to
subclass the new libvirt storage pool support thing and provide the
/dev/storpool/volumename paths to the upper layers.  If this is so, feel
free to let me know I've wasted your time in reading this e-mail, in strong
terms if necessary :)

G'luck,
Peter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141126/a0f849b3/attachment.html>