<div dir="ltr">Thanks Sean for bringing this up.<div><br></div><div>It's a known pain point that we discussed back in Tokyo [0].</div><div><br></div><div>Failures in class level fixtures are difficult to handle consistently, because there is no concept of success / failure at class level in the data model.</div><div><br></div><div>If a failure happens during setup, no test is actually executed. Marking all the tests in the class as skipped would provide false data. <span></span>Failures in setup are related to the creation / deletion of resources that are required by most test in the class, but not necessarily all of them. Because of that marking all the tests in the class as failed may also be non accurate - besides certain tests might have been skipped anyways, and they would be reported as failed for no good reason.</div><div><br></div><div>If a failure happens during cleanup, all tests already had a result, so what to do with the teardown failure? An option would be to avoid failing during teardown, and only log issues in cleanup as warnings.</div><div><br></div><div>Before we can fix this, we need to get an agreement on a way to treat these failures, and be are ready to accept the noise that might be added to the data.</div><div><br></div><div>Personally I would prefer to:</div><div>- fix tests so that we never fail in a tearDownClass (that should be easy to do)</div><div>- fix the test framework so that all tests are marked as failed upon failure in setUpClass</div><div><br></div><div>The downside of this approach is that it may require changes in each test framework that reports data in OpenStack Health.</div><div><br></div><div>andrea</div><div><br></div><div>[0] <a href="https://etherpad.openstack.org/p/mitaka-qa-testr-datastore-layering">https://etherpad.openstack.org/p/mitaka-qa-testr-datastore-layering</a></div></div><br><div class="gmail_quote"><div dir="ltr">On Wed, Mar 2, 2016 at 1:19 PM Sean Dague <<a href="mailto:sean@dague.net">sean@dague.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I noticed in looking at the last 10 failures in the gate view -<br>
<a href="http://status.openstack.org//openstack-health/#/" rel="noreferrer" target="_blank">http://status.openstack.org//openstack-health/#/</a> that 2 of them were<br>
tearDown in test_volume_boot_pattern.<br>
<br>
However, it looks like these don't count against the<br>
test_volume_boot_pattern success rate. Which means the real fail rate of<br>
the boot from volumes tests is not accounted for.<br>
<br>
Can we get that folded in correctly? I do realize the complexities of<br>
tearDownClass accounting. But it seems like that should be done here<br>
otherwise we don't really realize how bad our hot spots are.<br>
<br>
        -Sean<br>
<br>
--<br>
Sean Dague<br>
<a href="http://dague.net" rel="noreferrer" target="_blank">http://dague.net</a><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>
</blockquote></div>