[openstack-tc] [OpenStack-TC] Block Storage abstractions in Cinder

John Griffith john.griffith at solidfire.com
Mon Jul 14 16:03:29 UTC 2014


Hello TC Members,

Some of you have maybe heard my opinions and position on the so called
"Software Defined Storage" trend in Cinder.  For those that aren't familiar
here's the summary:

Basicly the first proposal from EMC came several months back where they
submitted a "Driver" that was an abstraction layer for multiple EMC and
non-EMC storage devices [1].  The goal being to provide a Cinder
Volume-Driver that implements an entire new abstraction and scheduling
layer for heterogenous devices that are connected behind an EMC VIPR node.
 The first problem I had with this was patch-set 1 was 28924 line code dump
of a "driver".  The second problem was the fact that it duplicates
scheduler, API abstraction etc.

My bigger concern is that every vendor and now some other Open Source
groups are also seeing this as a great marketing tool and potential for
driving some new sales in their company.  There have been additional
proposals for similar abstractions in the Juno cycle (and notification from
at least 2 other vendors that they'll be submitting something similar).
 For those that support a "software based storage on top of commodity
servers or JBODS" it seems reasonable/good to have a Cinder driver.  The
problem is you can't have just that piece of their product, you get all or
nothing.

The concept itself (and the implementation) in some of these is pretty cool
and I see real value in them.  What I don't see as beneficial however is
them being in the Cinder Source code.  I don't think that support and
overhead of maintaining entire duplications of the Cinder services is
necessarily a great idea.  To be honest, I've spent the last year trying to
figure out a reasonable way to have ZERO 3'rd party drivers in Cinder, and
still provide some way of providing quality.

Anyway, I'd like to get some feedback from the TC on all of this.  Whether
it be an official agenda item for an upcoming meeting, or at the very least
feedback to this email.  In my opinion this is very much a TC item and is
exactly the sort of thing that the TC should be interested in.  I can
certainly make decisions on my own based on feedback from the rest of the
Cinder community and my own personal view, however I believe this has a
broader impact.

Most of these products also extend at some point to direct integrations as
Object Stores, Image Repositories, Manilla Share Plugins and direct
integrations in to Nova.  I think it's something that needs to be well
thought out and the long terms impacts on the OpenStack projects should be
considered.

Thanks,
John


[1]: https://review.openstack.org/#/c/74158/

Additional/Similar proposals:
https://review.openstack.org/#/c/106742/
https://review.openstack.org/#/c/101688/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-tc/attachments/20140714/6e95a8e2/attachment.html>


More information about the OpenStack-TC mailing list