<div dir="ltr">Hi,<div><br></div><div>I will try to be short. </div><div><br></div><div><div>- Voting unit test coverage job is ready, and you can just use it as is from rally source code: </div><div>   you need this file <a href="https://github.com/openstack/rally/blob/master/tests/ci/cover.sh">https://github.com/openstack/rally/blob/master/tests/ci/cover.sh</a></div><div>   and this change in tox: <a href="https://github.com/openstack/rally/blob/master/tox.ini#L51-L52">https://github.com/openstack/rally/blob/master/tox.ini#L51-L52</a></div></div><div><br></div><div>- Rally is in gates, and it's easy to add jobs in any project. If you have any problems with this </div><div>  just ping me or someone from Rally team (or just write comment in openstack-rally IRC)</div><div><br></div><div>- Rally was a performance tool, however that change  and now we are more like common testing </div><div>  framework, that allows to do various kinds of testing (perf, volume, stress, functional, ...)</div><div><br></div><div>- In Rally we were testing all plugins with relative small concurrency (already for more then 1.5 year),</div><div>  and I can say that we faced a lot of issues with concurrency (and we are still facing).</div><div>  However I can't give guarantee that we are facing 100% of cases </div><div>  (however facing most of issues is better then nothing) </div><div><br></div><div><br></div><div><br></div><div>Best regards,</div><div>Boris Pavlovic </div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Mar 2, 2016 at 7:30 AM, Michał Dulko <span dir="ltr"><<a href="mailto:michal.dulko@intel.com" target="_blank">michal.dulko@intel.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 04:11 PM, Gorka Eguileor wrote:<br>
> On 02/03, Ivan Kolodyazhny wrote:<br>
>> Eric,<br>
>><br>
>> There are Gorka's patches [10] to remove API Races<br>
>><br>
>><br>
>> [10]<br>
>> <a href="https://review.openstack.org/#/q/project:openstack/cinder+branch:master+topic:fix/api-races-simplified" rel="noreferrer" target="_blank">https://review.openstack.org/#/q/project:openstack/cinder+branch:master+topic:fix/api-races-simplified</a><br>
>><br>
> I looked at Rally a long time ago so apologies if I'm totally off base<br>
> here, but it looked like it was a performance evaluation tool, which<br>
> means that it probably won't help to check for API Races (at least I<br>
> didn't see how when I looked).<br>
><br>
> Many of the API races only happen if you simultaneously try the same<br>
> operation multiple times against the same resource or if there are<br>
> different operations that are trying to operate on the same resource.<br>
><br>
> On the first case if Rally allowed it we could test it because we know<br>
> only 1 of the operations should succeed, but on the second case when we<br>
> are talking about preventing races from different operations there is no<br>
> way to know what the result should be, since the order in which those<br>
> operations are executed on each test run will determine which one will<br>
> fail and which one will succeed.<br>
><br>
> I'm not trying to go against the general idea of adding rally tests, I<br>
> just think that they won't help in the case of the API races.<br>
<br>
</span>You're probably right - Rally would need to cache API responses to<br>
parallel runs, predict the result of accepted requests (these which<br>
haven't received VolumeIsBusy) and then verify it. In case of API race<br>
conditions things explode inside the stack, and not on the API response<br>
level. The issue is that two requests, that shouldn't ever be accepted<br>
together, get positive API response.<br>
<br>
I cannot say it's impossible to implement a situation like that as Rally<br>
resource, but definitely it seems non-trivial to verify if result is<br>
correct.<br>
<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>