<div dir="ltr">Eric,<div><br></div><div>There are Gorka's patches [10] to remove API Races</div><div><br></div><div><br></div><div>[10] <a href="https://review.openstack.org/#/q/project:openstack/cinder+branch:master+topic:fix/api-races-simplified">https://review.openstack.org/#/q/project:openstack/cinder+branch:master+topic:fix/api-races-simplified</a></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 Wed, Mar 2, 2016 at 4:27 PM, Eric Harney <span dir="ltr"><<a href="mailto:eharney@redhat.com" target="_blank">eharney@redhat.com</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 03/02/2016 06:25 AM, Ivan Kolodyazhny wrote:<br>
> Hi Team,<br>
><br>
> Here are my thoughts and proposals how to make Cinder testing process<br>
> better. I won't cover "3rd party CI's" topic here. I will share my opinion<br>
> about current and feature jobs.<br>
><br>
><br>
> Unit-tests<br>
><br>
</span>>    - Long-running tests. I hope, everybody will agree that unit-tests must<br>
<span class="">>    be quite simple and very fast. Unit tests which takes more than 3-5 seconds<br>
>    should be refactored and/or moved to 'integration' tests.<br>
>    Thanks to Tom Barron for several fixes like [1]. IMO, we it would be<br>
>    good to have some hacking checks to prevent such issues in a future.<br>
><br>
</span>>    - Tests coverage. We don't check it in an automatic way on gates.<br>
<div><div class="h5">>    Usually, we require to add some unit-tests during code review process. Why<br>
>    can't we add coverage job to our CI and do not merge new patches, with<br>
>    will decrease tests coverage rate? Maybe, such job could be voting in a<br>
>    future to not ignore it. For now, there is not simple way to check coverage<br>
>    because 'tox -e cover' output is not useful [2].<br>
><br>
><br>
> Functional tests for Cinder<br>
><br>
> We introduced some functional tests last month [3]. Here is a patch to<br>
> infra to add new job [4]. Because these tests were moved from unit-tests, I<br>
> think we're OK to make this job voting. Such tests should not be a<br>
> replacement for Tempest. They even could tests Cinder with Fake Driver to<br>
> make it faster and not related on storage backends issues.<br>
><br>
><br>
> Tempest in-tree tests<br>
><br>
> Sean started work on it [5] and I think it's a good idea to get them in<br>
> Cinder repo to run them on Tempest jobs and 3-rd party CIs against a real<br>
> backend.<br>
><br>
><br>
> Functional tests for python-brick-cinderclient-ext<br>
><br>
> There are patches that introduces functional tests [6] and new job [7].<br>
><br>
><br>
> Functional tests for python-cinderclient<br>
><br>
> We've got a very limited set of such tests and non-voting job. IMO, we can<br>
> run them even with Cinder Fake Driver to make them not depended on a<br>
> storage backend and make it faster. I believe, we can make this job voting<br>
> soon. Also, we need more contributors to this kind of tests.<br>
><br>
><br>
> Integrated tests for python-cinderclient<br>
><br>
> We need such tests to make sure that we won't break Nova, Heat or other<br>
> python-cinderclient consumers with a next merged patch. There is a thread<br>
> in openstack-dev ML about such tests [8] and proposal [9] to introduce them<br>
> to python-cinderclient.<br>
><br>
><br>
> Rally tests<br>
><br>
> IMO, it would be good to have new Rally scenarios for every patches like<br>
> 'improves performance', 'fixes concurrency issues', etc. Even if we as a<br>
> Cinder community don't have enough time to implement them, we have to ask<br>
> for them in reviews, openstack-dev ML, file Rally bugs and blueprints if<br>
> needed.<br>
><br>
<br>
</div></div>Are there any recent examples of a fix like this recently where it would<br>
seem like a reasonable task to write a Rally scenario along with the patch?<br>
<br>
Not being very familiar with Rally (as I think most of us aren't), I'm<br>
having a hard time picturing this.<br>
<span class="im HOEnZb"><br>
><br>
> [1] <a href="https://review.openstack.org/#/c/282861/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/282861/</a><br>
> [2] <a href="http://paste.openstack.org/show/488925/" rel="noreferrer" target="_blank">http://paste.openstack.org/show/488925/</a><br>
> [3] <a href="https://review.openstack.org/#/c/267801/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/267801/</a><br>
> [4] <a href="https://review.openstack.org/#/c/287115/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/287115/</a><br>
> [5] <a href="https://review.openstack.org/#/c/274471/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/274471/</a><br>
> [6] <a href="https://review.openstack.org/#/c/265811/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/265811/</a><br>
> [7] <a href="https://review.openstack.org/#/c/265925/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/265925/</a><br>
> [8]<br>
> <a href="http://lists.openstack.org/pipermail/openstack-dev/2016-March/088027.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/2016-March/088027.html</a><br>
> [9] <a href="https://review.openstack.org/#/c/279432/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/279432/</a><br>
><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>
><br>
</span><div class="HOEnZb"><div class="h5">> __________________________________________________________________________<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>
__________________________________________________________________________<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>