<div dir="ltr">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.<br>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Jul 26, 2013 at 9:05 AM, Joshua Harlow <span dir="ltr"><<a href="mailto:harlowja@yahoo-inc.com" target="_blank">harlowja@yahoo-inc.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">



<div style="font-size:14px;font-family:Calibri,sans-serif;word-wrap:break-word">
<div>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.</div>
<div><br>
</div>
<div>Could it be possible to have CI gating be blocked/tested by individual subfolders of cinder.</div>
<div><br>
</div>
<div>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. </div>
<div><br>
</div>
<div>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 appears.</div>
<div><br>
</div>
<span>
<div style="border-right:medium none;padding-right:0in;padding-left:0in;padding-top:3pt;text-align:left;font-size:11pt;border-bottom:medium none;font-family:Calibri;border-top:#b5c4df 1pt solid;padding-bottom:0in;border-left:medium none">

<span style="font-weight:bold">From: </span>John Griffith <<a href="mailto:john.griffith@solidfire.com" target="_blank">john.griffith@solidfire.com</a>><br>
<span style="font-weight:bold">Reply-To: </span>OpenStack Development Mailing List <<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a>><br>
<span style="font-weight:bold">Date: </span>Thursday, July 25, 2013 5:44 PM<br>
<span style="font-weight:bold">To: </span>OpenStack Development Mailing List <<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a>><br>
<span style="font-weight:bold">Subject: </span>[openstack-dev] [OpenStack][Cinder] Driver qualification<br>
</div><div><div class="h5">
<div><br>
</div>
<div>
<div>
<div dir="ltr">
<div class="gmail_default" style="font-family:courier new,monospace">Hey Everyone,</div>
<div class="gmail_default" style="font-family:courier new,monospace"><br>
</div>
<div class="gmail_default" style="font-family:courier new,monospace">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.</div>
<div class="gmail_default" style="font-family:courier new,monospace"><br>
</div>
<div class="gmail_default" style="font-family:courier new,monospace">To elaborate a bit, the idea could start as something really simple like the following:</div>
<div class="gmail_default" style="font-family:courier new,monospace">1. We'd add a functional_qual option/script to devstack</div>
<div class="gmail_default" style="font-family:courier new,monospace"><br>
</div>
<div class="gmail_default" style="font-family:courier new,monospace">2. Driver maintainer runs this script to setup devstack and configure it to use their backend device on their own system.</div>
<div class="gmail_default" style="font-family:courier new,monospace"><br>
</div>
<div class="gmail_default" style="font-family:courier new,monospace">3. Script does the usual devstack install/configure and runs the volume pieces of the Tempest gate tests.</div>
<div class="gmail_default" style="font-family:courier new,monospace"><br>
</div>
<div class="gmail_default" style="font-family:courier new,monospace">4. Grabs output and checksums of the directories in the devstack and /opt/stack directories, bundles up the results for submission</div>
<div class="gmail_default" style="font-family:courier new,monospace"><br>
</div>
<div class="gmail_default" style="font-family:courier new,monospace">5. Maintainer submits results</div>
<div class="gmail_default" style="font-family:courier new,monospace"><br>
</div>
<div class="gmail_default" style="font-family:courier new,monospace">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.</div>
<div class="gmail_default" style="font-family:courier new,monospace"><br>
</div>
<div class="gmail_default" style="font-family:courier new,monospace">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.</div>

<div class="gmail_default" style="font-family:courier new,monospace"><br>
</div>
<div class="gmail_default" style="font-family:courier new,monospace">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.</div>
<div class="gmail_default" style="font-family:courier new,monospace"><br>
</div>
<div class="gmail_default" style="font-family:courier new,monospace">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.</div>
<div class="gmail_default" style="font-family:courier new,monospace"><br>
</div>
<div class="gmail_default" style="font-family:courier new,monospace">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.</div>
<div class="gmail_default" style="font-family:courier new,monospace"><br>
</div>
<div class="gmail_default" style="font-family:courier new,monospace">Anyway, I'd love to get feed-back from folks and see what they think.</div>
<div class="gmail_default" style="font-family:courier new,monospace"><br>
</div>
<div class="gmail_default" style="font-family:courier new,monospace">Thanks,</div>
<div class="gmail_default" style="font-family:courier new,monospace">John</div>
<div class="gmail_default" style="font-family:courier new,monospace"><br>
</div>
</div>
</div>
</div>
</div></div></span>
</div>

<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br>Regards<br>Huang Zhiteng
</div>