[openstack-dev] [OpenStack][Cinder] Driver qualification
winston.d at gmail.com
Fri Jul 26 01:18:15 UTC 2013
Great idea and 100% agree. It'd be even better if maintainer can publish
functional test results using their own back-ends on a regular basis
(weekly/bi-weekly test report) to 'openstack-dev' mailing list.
On Fri, Jul 26, 2013 at 9:05 AM, Joshua Harlow <harlowja at yahoo-inc.com>wrote:
> 100% agree, its hard to handle these 3rd party type of drivers but I
> think we need to find out a way that will test it in a way that doesn't
> require having said 3rd party gear directly available.
> Could it be possible to have CI gating be blocked/tested by individual
> subfolders of cinder.
> For example when the solidfire driver is modified, this would cause a
> 'trigger' to say solidfire (via some API) that solidfire can respond with
> back saying said commit works.
> Not sure if that’s feasible, but it does seem to be a similar situation
> in nova, neturon, cinder as more and more 3rd party 'driver-like' code
> From: John Griffith <john.griffith at solidfire.com>
> Reply-To: OpenStack Development Mailing List <
> openstack-dev at lists.openstack.org>
> Date: Thursday, July 25, 2013 5:44 PM
> To: OpenStack Development Mailing List <openstack-dev at lists.openstack.org>
> Subject: [openstack-dev] [OpenStack][Cinder] Driver qualification
> Hey Everyone,
> Something I've been kicking around for quite a while now but never
> really been able to get around to is the idea of requiring that drivers in
> Cinder run a qualification test and submit results prior to introduction in
> to Cinder.
> To elaborate a bit, the idea could start as something really simple like
> the following:
> 1. We'd add a functional_qual option/script to devstack
> 2. Driver maintainer runs this script to setup devstack and configure it
> to use their backend device on their own system.
> 3. Script does the usual devstack install/configure and runs the volume
> pieces of the Tempest gate tests.
> 4. Grabs output and checksums of the directories in the devstack and
> /opt/stack directories, bundles up the results for submission
> 5. Maintainer submits results
> So why would we do this you ask? Cinder is pretty heavy on the third
> party driver plugin model which is fantastic. On the other hand while
> there are a lot of folks who do great reviews that catch things like syntax
> or logic errors in the code, and unit tests do a reasonable job of
> exercising the code it's difficult for folks to truly verify these devices
> all work.
> I think it would be a very useful tool for initial introduction of a new
> driver and even perhaps some sort of check that's run and submitted again
> prior to milestone releases.
> This would also drive some more activity and contribution in to Tempest
> with respect to getting folks like myself motivated to contribute more
> tests (particularly in terms of new functionality) in to Tempest.
> I'd be interested to hear if folks have any interest or strong opinions
> on this (positive or otherwise). I know that some vendors like RedHat have
> this sort of thing in place for certifications, and to be honest that
> observation is something that caused me to start thinking about this again.
> There are a lot of gaps here regarding how the submission process would
> look, but we could start relatively simple and grow from there if it's
> valuable or just abandon the idea if it proves to be unpopular and a waste
> of time.
> Anyway, I'd love to get feed-back from folks and see what they think.
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev