Open Stack

I think having the rebranded drivers is fine (yay for effective code
re-use, right?), but they shouldn't have any special treatment. I don't
like the idea of having different categories of volume drivers where some
require CI and some don't.

As far as I know, in this specific case, they already have a CI system for
the 'base' driver, it should be trivial to add tests for the other drivers
too at this point.

-Patrick

On Wed, Jun 3, 2015 at 10:59 AM, John Griffith <john.griffith8 at gmail.com>
wrote:

>
>
> On Wed, Jun 3, 2015 at 11:32 AM, Mike Perez <thingee at gmail.com> wrote:
>
>> There are a couple of cases [1][2] I'm seeing where new Cinder volume
>> drivers for Liberty are rebranding other volume drivers. This involves
>> inheriting off another volume driver's class(es) and providing some
>> config options to set the backend name, etc.
>>
>> Two problems:
>>
>> 1) There is a thought of no CI [3] is needed, since you're using
>> another vendor's driver code which does have a CI.
>>
>> 2) IMO another way of satisfying a check mark of being OpenStack
>> supported and disappearing from the community.
>>
>> What gain does OpenStack get from these kind of drivers?
>>
>> Discuss.
>>
>> [1] - https://review.openstack.org/#/c/187853/
>> [2] - https://review.openstack.org/#/c/187707/4
>> [3] - https://wiki.openstack.org/wiki/Cinder/tested-3rdParty-drivers
>>
>> --
>> Mike Perez
>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
> ​This case is interesting​ mostly because it's the same contractor
> submitting the driver for all the related platforms.  Frankly I find the
> whole rebranding annoying, but there's certainly nothing really wrong with
> it, and well... why not, it's Open Source.
>
> What I do find annoying is the lack of give back; so this particular
> contributor has submitted a few drivers thus far (SCST, DotHill and some
> others IIRC), and now has three more proposed. This would be great except I
> personally have spent a very significant amount of time with this person
> helping with development, CI and understanding OpenStack and Cinder.
>
> To date, I don't see that he's provided a single code review (good or bad)
> or contributed anything back other than to his specific venture.
>
> Anyway... I think your point was for input on the two questions:
>
> For item '1':
> I guess as silly as it seems they should probably have 3'rd party CI.
> There are firmware differences etc that may actually change behaviors, or
> things my diverge, or maybe their code is screwed up and the inheritance
> doesn't work (doubtful).
>
> Yes, it's just a business venture in this case (good or bad, not for me to
> decide).  The fact is we don't discriminate or place a value on peoples
> contributions, and this shouldn't be any different.  I think the best
> answer is "follow same process for any driver" and move on.  This does
> point out that maybe OpenStack/Cinder has grown to a point where there are
> so many options and choices that it's time to think about changing some of
> the policies and ways we do things.
>
> In my opinion, OpenStack doesn't gain much in this particular case, which
> brings me back to;
> remove all drivers except the ref-impl and have them pip installable and
> on a certified list based on CI.
>
> Thanks,
> John
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150603/dc9ecdfb/attachment.html>