<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Mar 31, 2021 at 8:04 PM Wesley Hayutin <<a href="mailto:whayutin@redhat.com">whayutin@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"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Feb 10, 2021 at 1:05 PM Dan Smith <<a href="mailto:dms@danplanet.com" target="_blank">dms@danplanet.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">> Here's the timing I see locally:<br>
> Vanilla devstack: 775<br>
> Client service alone: 529<br>
> Parallel execution: 527<br>
> Parallel client service: 465<br>
><br>
> Most of the difference between the last two is shorter async_wait<br>
> times because the deployment steps are taking less time. So not quite<br>
> as much as before, but still a decent increase in speed.<br>
<br>
Yeah, cool, I think you're right that we'll just serialize the<br>
calls. It may not be worth the complexity, but if we make the OaaS<br>
server able to do a few things in parallel, then we'll re-gain a little<br>
more perf because we'll go back to overlapping the *server* side of<br>
things. Creating flavors, volume types, networks and uploading the image<br>
to glance are all things that should be doable in parallel in the server<br>
projects.<br>
<br>
465s for a devstack is awesome. Think of all the developer time in<br>
$local_fiat_currency we could have saved if we did this four years<br>
ago...  :)<br>
<br>
--Dan<br>
<br></blockquote><div><br></div><div>Hey folks,</div><div>Just wanted to check back in on the resource consumption topic.</div><div>Looking at my measurements the TripleO group has made quite a bit of progress keeping our enqued zuul time lower than our historical average.</div><div>Do you think we can measure where things stand now and have some new numbers available at the PTG?</div><div><br></div><div>/me notes we had a blip on 3/25 but there was a one off issue w/ nodepool in our gate.</div><div><br></div><div>Marios Andreou has put a lot of time into this, and others as well.  Kudo's Marios!</div><div>Thanks all!</div></div></div></blockquote><div><br></div><div>o/ thanks for the shout out ;)</div><div><br></div><div></div><div>Big thanks to Sagi (sshnaidm), Chandan (chkumar), Wes (weshay), Alex (mwhahaha) and everyone else who helped us merge those things <a href="https://review.opendev.org/q/topic:tripleo-ci-reduce">https://review.opendev.org/q/topic:tripleo-ci-reduce</a> - things like tightening files/irrelevant_files matches, removal of older/non voting jobs, removal of upgrade master jobs and removal of layout overrides across tripleo repos (using the centralised tripleo-ci repo templates everywhere instead)  to make maintenance easier so it is more likely that we will notice and fix new issues moving forward</div><div><br></div><div>regards, marios</div><div> </div></div></div>