On 6/3/15 6:16 PM, Bruns, Curt E wrote: > > >> -----Original Message----- >> From: Eric Harney [mailto:ehar...@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 <thin...@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-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
Well said. -- Tom __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev