<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>+1. I like this idea. With this qualification test, is each driver still required to have its own unit test?</div><div><br></div><div>Thanks,</div><div>Xing<br><br></div><div><br>On Jul 25, 2013, at 8:46 PM, "John Griffith" <<a href="mailto:john.griffith@solidfire.com">john.griffith@solidfire.com</a>> wrote:<br><br></div><blockquote type="cite"><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></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>OpenStack-dev mailing list</span><br><span><a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a></span><br><span><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a></span><br></div></blockquote></body></html>