Open Stack

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