<div dir="ltr">Sean, <div><br></div><div>I do understand why we have tempest for python-cinderclient now. </div><div><br></div><div>But my point is: tempest runs more than 200 tests per each cinderclient change request which takes a lot of time. Why can't we just introduce few integration tests which will tests nova<=>python-cinderclient API. </div><div><br></div><div>Also, Nova is not only one consumer of cinderclient. What about Heat? We don't want to break it too but to run all Heat-related Tempest tests is not a good idea. We have to implement integration tests between Heat and python-cinderclient too.</div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div dir="ltr"><div>Regards,<br>Ivan Kolodyazhny,<br><a href="http://blog.e0ne.info/" target="_blank">http://blog.e0ne.info/</a></div></div></div></div>
<br><div class="gmail_quote">On Tue, Feb 16, 2016 at 2:05 PM, Sean Dague <span dir="ltr"><<a href="mailto:sean@dague.net" target="_blank">sean@dague.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 02/15/2016 02:48 PM, Ivan Kolodyazhny wrote:<br>
> Hi all,<br>
><br>
> I'll talk mostly about python-cinderclient but the same question could<br>
> be related for other clients.<br>
><br>
> Now, for python-cinderclient we've got to kinds for<br>
> functional/integrated jobs:<br>
><br>
> 1) gate-cinderclient-dsvm-functional - a very limited (for now) set of<br>
> functional tests, most of them were part of tempest CLI tests in the past.<br>
><br>
> 2) gate-tempest-dsvm-neutron-src-python-cinderclient - if I understand<br>
> right, the idea os this job was to have integrated tests to test<br>
> cinderclient with other projects to verify that new patch to<br>
> python-cinderclietn won't break any other project.<br>
> But it does *not* test cinderclient at all, except few attach-related<br>
> tests because Tempest doesn't use python-*client.<br>
<br>
</span>This does test the real world usage of Nova consuming<br>
python-cinderclient. That's why it's still there. This ensures that a<br>
cinderclient upcoming release won't completely tank the integrated gate.<br>
All openstack libraries that get used by all servers in openstack have<br>
something equivalent.<br>
<span class=""><br>
> The same job was added for python-heatclient but was removed because<br>
> devstack didn't install Heat for that job [1].<br>
><br>
> We agreed [2] to remove this job from cinderclient gates too, once<br>
> functional or integration tests will be implemented.<br>
<br>
</span>Um, what now?<br>
<span class="im HOEnZb"><br>
> There is a proposal to python-cinderclient tests to implement some<br>
> cross-project testing to make sure, that new python-cinderclient won't<br>
> break any of existing project who use it.<br>
><br>
> After discussing in IRC with John Griffith (jgriffith) I'm realized that<br>
> it could be an cross-project initiative in such kind of integration<br>
> tests. OpenStack Client (OSC) could cover some part of such tests, but<br>
> does it mean that we'll run OSC tests on every patch to python-*client?<br>
> We can run only cinder-realated OSC tests on our gates to verify that it<br>
> doesn't breack OSC and, may be other project.<br>
><br>
> The other option, is to implement tests like [3] per project basis and<br>
> call it "integration".  Such tests could cover more cases than OSC<br>
> functional tests and have more project-related test cases, e.g.: test<br>
> some python-cinderclient specific corner cases, which is not related to OSC.<br>
><br>
> IMO, It would be good to have some cross-project decision on how will be<br>
> implement clients' integration tests per project.<br>
><br>
><br>
> [1] <a href="https://review.openstack.org/#/c/272411/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/272411/</a><br>
> [2]<br>
> <a href="http://eavesdrop.openstack.org/meetings/cinder/2015/cinder.2015-12-16-16.00.log.html" rel="noreferrer" target="_blank">http://eavesdrop.openstack.org/meetings/cinder/2015/cinder.2015-12-16-16.00.log.html</a><br>
> [3] <a href="https://review.openstack.org/#/c/279432/8" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/279432/8</a><br>
><br>
> Regards,<br>
> Ivan Kolodyazhny,<br>
> <a href="http://blog.e0ne.info/" rel="noreferrer" target="_blank">http://blog.e0ne.info/</a><br>
><br>
><br>
</span><span class="im HOEnZb">> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
<br>
<br>
</span><span class="HOEnZb"><font color="#888888">--<br>
Sean Dague<br>
<a href="http://dague.net" rel="noreferrer" target="_blank">http://dague.net</a><br>
</font></span><div class="HOEnZb"><div class="h5"><br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div>