<div dir="ltr">These jobs seem to timeout from every provider on the regular[1], but the issue is surely more apparent with tempest on FN. The result is quite a bit of lost time. 361 jobs that run for several hours results in a little over a 1000 hours of lost cycles. <div><br></div><div>[1] <a href="http://logstash.openstack.org/#/dashboard/file/logstash.json?query=filename:%5C%22job-output.txt%5C%22%20AND%20message:%5C%22RUN%20END%20RESULT_TIMED_OUT%5C%22&from=7d">http://logstash.openstack.org/#/dashboard/file/logstash.json?query=filename:%5C%22job-output.txt%5C%22%20AND%20message:%5C%22RUN%20END%20RESULT_TIMED_OUT%5C%22&from=7d</a></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Aug 1, 2019 at 5:01 AM Ian Wienand <<a href="mailto:iwienand@redhat.com">iwienand@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Fri, Jul 26, 2019 at 04:53:28PM -0700, Clark Boylan wrote:<br>
> Given my change shows this can be so much quicker is there any<br>
> interest in modifying devstack to be faster here? And if so what do<br>
> we think an appropriate approach would be?<br>
<br>
My first concern was if anyone considered openstack-client setting<br>
these things up as actually part of the testing.  I'd say not,<br>
comments in [1] suggest similar views.<br>
<br>
My second concern is that we do keep sufficient track of complexity v<br>
speed; obviously doing things in a sequential manner via a script is<br>
pretty simple to follow and as we start putting things into scripts we<br>
make it harder to debug when a monoscript dies and you have to start<br>
pulling apart where it was.  With just a little json fiddling we can<br>
currently pull good stats from logstash ([2]) so I think as we go it<br>
would be good to make sure we account for the time using appropriate<br>
wrappers, etc.<br>
<br>
Then the third concern is not to break anything for plugins --<br>
devstack has a very very loose API which basically relies on plugin<br>
authors using a combination of good taste and copying other code to<br>
decide what's internal or not.<br>
<br>
Which made me start thinking I wonder if we look at this closely, even<br>
without replacing things we might make inroads?<br>
<br>
For example [3]; it seems like SERVICE_DOMAIN_NAME is never not<br>
default, so the get_or_create_domain call is always just overhead (the<br>
result is never used).<br>
<br>
Then it seems that in the gate, basically all of the "get_or_create"<br>
calls will really just be "create" calls?  Because we're always<br>
starting fresh.  So we could cut out about half of the calls there<br>
pre-checking if we know we're under zuul (proof-of-concept [4]).<br>
<br>
Then we have blocks like:<br>
<br>
  get_or_add_user_project_role $member_role $demo_user $demo_project<br>
  get_or_add_user_project_role $admin_role $admin_user $demo_project<br>
  get_or_add_user_project_role $another_role $demo_user $demo_project<br>
  get_or_add_user_project_role $member_role $demo_user $invis_project<br>
<br>
If we wrapped that in something like<br>
<br>
 start_osc_session<br>
 ...<br>
 end_osc_session<br>
<br>
which sets a variable that means instead of calling directly, those<br>
functions write their arguments to a tmp file.  Then at the end call,<br>
end_osc_session does<br>
<br>
 $ osc "$(< tmpfile)"<br>
<br>
and uses the inbuilt batching?  If that had half the calls by skipping<br>
the "get_or" bit, and used common authentication from batching, would<br>
that help?<br>
<br>
And then I don't know if all the projects and groups are required for<br>
every devstack run?  Maybe someone skilled in the art could do a bit<br>
of an audit and we could cut more of that out too?<br>
<br>
So I guess my point is that maybe we could tweak what we have a bit to<br>
make some immediate wins, before anyone has to rewrite too much?<br>
<br>
-i<br>
<br>
[1] <a href="https://review.opendev.org/673018" rel="noreferrer" target="_blank">https://review.opendev.org/673018</a><br>
[2] <a href="https://ethercalc.openstack.org/rzuhevxz7793" rel="noreferrer" target="_blank">https://ethercalc.openstack.org/rzuhevxz7793</a><br>
[3] <a href="https://review.opendev.org/673941" rel="noreferrer" target="_blank">https://review.opendev.org/673941</a><br>
[4] <a href="https://review.opendev.org/673936" rel="noreferrer" target="_blank">https://review.opendev.org/673936</a><br>
<br>
</blockquote></div>