Open Stack

On 6/3/15 6:16 PM, Bruns, Curt E wrote:
> 
> 
>> -----Original Message-----
>> From: Eric Harney [mailto:eharney at redhat.com]
>> Sent: Wednesday, June 03, 2015 12:54 PM
>> To: OpenStack Development Mailing List (not for usage questions)
>> Subject: Re: [openstack-dev] [cinder] Rebranded Volume Drivers
>>
>> On 06/03/2015 01:59 PM, John Griffith 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
>>>>
>>>
>>> ​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).
>>
>> Given that part of the case made for CI was "ensure that Cinder ships drivers
>> that work", the case of backend behavior diverging over time from what
>> originally worked with Cinder seems like a valid concern.  We lose the ability to
>> keep tabs on that for derived drivers without CI.
>>
>>>
>>> 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
>>>
>>
>> The other issue I see with not requiring CI for "derived" drivers is that,
>> inevitably, small changes will be made to the driver code, and we will find
>> ourselves having to sort out how much change can happen before CI is then
>> required.  I don't know how to define that in a way that would be useful as a
>> general policy.
>>
>> Eric
>>
> 
> I haven't been involved in this project too long, but I have learned that if you want a driver included, you need to provide a CI system.  It's a very clearly documented requirement.  I'm all for inheritance and re-use, but along with what Eric said, at some point the HW/FW in those also-supported/re-branded arrays may change and if it's not being tested, then who knows what kind of end-user experience will occur.  I'd be surprised if someone standing up OpenStack with Lenovo Storage would be okay knowing that it's never been tested on actual HW.
> 
> - Curt
> 
> 
> __________________________________________________________________________
> 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
> 

Well said.

-- Tom