On 06/03/2015 02:53 PM, Eric Harney wrote:
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
__________________________________________________________________________
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
At first I wasn't too sure that requiring an additional CI for a derived
driver made sense. The concerns raised, however, are compelling and I
think that a CI should be required for rebranded drivers. It is
inevitable that subtle differences will sneak in and we need to have CI
in place to catch any failures that may also be introduced.
Jay
__________________________________________________________________________
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
