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.griffi...@gmail.com> 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 >> >> __________________________________________________________________________ >> 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 >> > > 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-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
__________________________________________________________________________ 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