> -----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