<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Mon, Apr 17, 2017 at 7:58 PM Ihar Hrachyshka <<a href="mailto:ihrachys@redhat.com">ihrachys@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Mon, Apr 17, 2017 at 9:35 AM, Jordan Pittier<br>
<<a href="mailto:jordan.pittier@scality.com" target="_blank">jordan.pittier@scality.com</a>> wrote:<br>
> We don"t run slow tests because the QA team think that they don't bring<br>
> enough value to be executed, every time and everywhere. The idea is that if<br>
> some specific slow tests are of some interest to some specific openstack<br>
> projects, those projects can change the config of their jobs to enable these<br>
> tests.<br>
<br>
<br>
But since it's not executed anywhere in tempest gate, even as<br>
non-voting (?), it's effectively dead code that may be long broken<br>
without anyone knowing. Of course there are consumers of the tests<br>
downstream, but for those consumers it's a tough call to start<br>
depending on the tests if they are not sanity checked by tempest<br>
itself. Wouldn't it make sense to have some job in tempest gate that<br>
would execute those tests (maybe just them to speed up such a job?<br>
maybe non-voting? </blockquote><div><br></div><div>We reduced the number of scenario tests we run in the main gate because some of those tests are not so</div><div>critical for the integrated gate, and also because we had an unstable gate we had to deal with to allow for</div><div>Pike development to happen. </div><div><br></div><div>The SUT was overloaded in the gate, due to a combination of effects: too many services running, many</div><div>consuming more memory that it did in the past, as well as too many "heavy" tests running in parallel.</div><div><br></div><div>As soon as removed scenario tests from the main gate we introduced a new non-voting job against </div><div>Tempest, which runs *all* scenario tests against a multimode environment, see for instance [0], so</div><div>we can ensure the code is not dead as long as it lives in Tempest.</div><div><br></div><div>I'm planning to add more "heavy/long" tests to that jobs, e.g. compute migrate ones [1].</div><div><br></div><div>andreaf</div><div><br></div><div>[0] <a href="http://logs.openstack.org/69/451769/2/check/gate-tempest-dsvm-neutron-scenario-multinode-ubuntu-xenial-nv/1f71416/">http://logs.openstack.org/69/451769/2/check/gate-tempest-dsvm-neutron-scenario-multinode-ubuntu-xenial-nv/1f71416/</a> </div><div>[1] <a href="https://review.openstack.org/#/c/451769/">https://review.openstack.org/#/c/451769/</a> </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">maybe even as periodic? but there should be<br>
something that keeps it green in long run).<br>
<br>
Ihar<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></div>