<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 21 March 2016 at 04:15, Rossella Sblendido <span dir="ltr"><<a href="mailto:rsblendido@suse.com" target="_blank">rsblendido@suse.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello all,<br>
<br>
the tests that we run on the gate for Neutron take pretty long (longer<br>
than one hour). I think we can improve that and make better use of the<br>
resources.</blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Here are some ideas that came up when Ihar and I discussed this topic<br>
during the sprint in Brno:<br>
<br>
1) We have few jobs that are non-voting. I think it's OK to have<br>
non-voting jobs for a limited amount of time, while we try to make them<br>
stable but this shouldn't be too long, otherwise we waste time running<br>
those tests without even using the results. If a job is still not-voting<br>
after 3 months (or 4 or 6, we can find a good time interval) the job<br>
should be removed. My hope is that this threat will make us find some<br>
time to actually fix the job and make it vote :)<br>
<br>
2) multi-node jobs run for every patch set. Is that really what we want?<br>
They take pretty long. We could move them to a periodic job. I know we<br>
can easily forget about periodic jobs, to avoid that we could run them<br>
in the gate queue too. If a patch can't merge because of a failure we<br>
will fix the issue. To trigger them for a specific patch that might<br>
affect multi-node we can run the experimental jobs.<br>
<br>
Thoughts?<br></blockquote><div><br></div><div>Thanks for raising the topic. That said, I am not sure I see how what you propose is going to make things better. Jobs, either non voting or multnode run in parallel, thus reducing the number of jobs won't reduce the time to feedback though it would improve resource usage. We are already pretty conscious of that and compared to other projects we already run a limited numbers of jobs, but we can do better, of course.</div><div><br></div><div>Do you have an a better insight of job runtimes vs jobs in other projects? Most of the time in the job runtime is actually spent setting the infrastructure up, and I am not sure we can do anything about it, unless we take this with Infra.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Rossella<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><br></div></div>