Open Stack

On Tue, Jul 15, 2014 at 8:56 AM, Thierry Carrez <thierry at openstack.org> wrote:
> John Griffith wrote:
>> [...]
>> 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.
>
> The TC is responsible for the "scope" of OpenStack and making sure we
> spend our common resources where they are the most needed, so I think
> it's relevant for us to at least give our opinion there.
>
> There are IMHO two different issues here. The first is a technical
> issue: what type of functionality you want your drivers to cover. In
> Cinder, drivers should be a relatively thin indirection layer where you
> implement the glue between the Cinder driver API on one side and what
> the pure storage backend expects on the other. They are not really
> supposed to be big or reimplement advanced scheduling features.
> Accepting such monster drivers in mainline code changes the relative
> weight of code areas in cinder and therefore makes it a costly
> maintenance proposition for the project, with little on the benefits
> side compared to growing that driver out of tree.
>
> The second issue is more of a social issue: we want as much as possible
> of the smart in Cinder being implemented in open source in OpenStack. If
> vendors decide to implement the smart parts in closed source software
> shipped in storage hardware gateways, they may win but OpenStack surely
> loses.
>
> I think it's a perfect example of where out-of-tree makes the most
> sense: when the added value to the project is limited (or negative),
> while the benefit for one vendor is enormous.

We also need to keep in mind the DefCore discussions, and the TC
position that the code the community delivers in the integrated
release should be used as the "designated sections". Vendors want to
use the trademark. We want them to contribute to core. Working
together on their drivers in the tree is part of the bargain, and it
would be a huge mistake to push them out.

If this particular driver reproduces too much existing cinder
functionality in a way that can't be reused, that's both a technical
issue and a project management issue. Maybe the new initiative to
bring product managers into the community will address it in the
future by helping them to understand how to work on features with the
community. In the mean time I don't have a problem with the Cinder
team responding to this contribution that it duplicates functionality
in their core, and is therefore not an appropriate implementation for
a driver. As long we suggest changes rather than rejecting it
entirely, that sort of review is part of the process. Would a spec
review have caught this earlier?

We should also consider writing down guidelines for what sort of
functionality should and should not be included in the various driver
layers, to help vendors understand our expectations.

Doug

> The other classic example of this is the Nova VMWare support... and it's
> questionable as well on both counts. That said the dynamics are slightly
> different there, VMWare being the legacy standard for old-style
> datacenter virtualization, supporting it is a decent way to co-opt that
> ecosystem and encourage migrating off it.
>
> --
> Thierry Carrez (ttx)
>
> _______________________________________________
> OpenStack-TC mailing list
> OpenStack-TC at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-tc