Open Stack

We have a similar (but I suspect less severe) issue in nova -- some
companies have chose to provide what I will call "cluster drivers",
which are drivers that make calls to their existing clustering
solutions. So vmware for example is built so we don't have a
nova-compute per hypervisor node, but one per cluster, and then rely
on vsphere to do all the cluster leg work. This isn't as bad as it
sounds like it is in cinder, but is still a watering down in the value
of nova.

I'm not completely opposed to this model -- ironic does something
similar for example -- but I do feel we're on a slippery slope and
need to be careful.

Michael

On Tue, Jul 15, 2014 at 2:03 AM, John Griffith
<john.griffith at solidfire.com> wrote:
> 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/
>
> _______________________________________________
> OpenStack-TC mailing list
> OpenStack-TC at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-tc
>



-- 
Rackspace Australia