<div dir="ltr">Just for reference FortNebula does 73-80 jobs an hour, so that's 1700(ish) jobs a day -3 minutes per job. <div><br></div><div>That is 5200(ish) cycle minutes a day.  Or about 4 days worth of computing time. </div><div><br></div><div>If there can be a fix that saves minutes, its surely worth it. </div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Aug 7, 2019 at 1:18 PM Sean Mooney <<a href="mailto:smooney@redhat.com">smooney@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 Wed, 2019-08-07 at 10:11 -0500, Ben Nemec wrote:<br>
> <br>
> On 8/7/19 9:37 AM, Sean Mooney wrote:<br>
> > On Wed, 2019-08-07 at 08:33 -0500, Ben Nemec wrote:<br>
> > > <br>
> > > On 8/6/19 11:34 AM, Ben Nemec wrote:<br>
> > > > <br>
> > > > <br>
> > > > On 8/6/19 10:49 AM, Clark Boylan wrote:<br>
> > > > > On Tue, Aug 6, 2019, at 8:26 AM, Ben Nemec wrote:<br>
> > > > > > Just a reminder that there is also<br>
> > > > > > <a href="http://lists.openstack.org/pipermail/openstack-dev/2016-April/092546.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/2016-April/092546.html</a><br>
> > > > > > <br>
> > > > > > which was intended to address this same issue.<br>
> > > > > > <br>
> > > > > > I toyed around with it a bit for TripleO installs back then and it did<br>
> > > > > > seem to speed things up, but at the time there was a bug in our client<br>
> > > > > > plugin where it was triggering a prompt for input that was problematic<br>
> > > > > > with the server running in the background. I never really got back to it<br>
> > > > > > once that was fixed. :-/<br>
> > > > > <br>
> > > > > I'm not tied to any particular implementation. Mostly I wanted to show<br>
> > > > > that we can take this ~5 minute portion of devstack and turn it into a<br>
> > > > > 15 second portion of devstack by improving our use of the service APIs<br>
> > > > > (and possibly even further if we apply it to all of the api<br>
> > > > > interaction). Any idea how difficult it would be to get your client as<br>
> > > > > a service stuff running in devstack again?<br>
> > > > <br>
> > > > I wish I could take credit, but this is actually Dan Berrange's work. :-)<br>
> > > > <br>
> > > > > <br>
> > > > > I do not think we should make a one off change like I've done in my<br>
> > > > > POC. That will just end up being harder to understand and debug in the<br>
> > > > > future since it will be different than all of the other API<br>
> > > > > interaction. I like the idea of a manifest or feeding a longer lived<br>
> > > > > process api update commands as we can then avoid requesting new tokens<br>
> > > > > as well as pkg_resource startup time. Such a system could be used by<br>
> > > > > all of devstack as well (avoiding the "this bit is special" problem).<br>
> > > > > <br>
> > > > > Is there any interest from the QA team in committing to an approach<br>
> > > > > and working to do a conversion? I don't want to commit any more time<br>
> > > > > to this myself unless there is strong interest in getting changes<br>
> > > > > merged (as I expect it will be a slow process weeding out places where<br>
> > > > > we've made bad assumptions particularly around plugins).<br>
> > > > > <br>
> > > > > One of the things I found was that using names with osc results in<br>
> > > > > name to id lookups as well. We can avoid these entirely if we remember<br>
> > > > > name to id mappings instead (which my POC does). Any idea if your osc<br>
> > > > > as a service tool does or can do that? Probably have to be more<br>
> > > > > careful for scoping things in a tool like that as it may be reused by<br>
> > > > > people with name collisions across projects/users/groups/domains.<br>
> > > > <br>
> > > > I don't believe this would handle name to id mapping. It's a very thin<br>
> > > > wrapper around the regular client code that just makes it persistent so<br>
> > > > we don't pay the startup costs every call. On the plus side that means<br>
> > > > it basically works like the vanilla client, on the minus side that means<br>
> > > > it may not provide as much improvement as a more targeted solution.<br>
> > > > <br>
> > > > IIRC it's pretty easy to use, so I can try it out again and make sure it<br>
> > > > still works and still provides a performance benefit.<br>
> > > <br>
> > > It still works and it still helps. Using the osc service cut about 3<br>
> > > minutes off my 21 minute devstack run. Subjectively I would say that<br>
> > > most of the time was being spent cloning and installing services and<br>
> > > their deps.<br>
> > > <br>
> > > I guess the downside is that working around the OSC slowness in CI will<br>
> > > reduce developer motivation to fix the problem, which affects all users<br>
> > > too. Then again, this has been a problem for years and no one has fixed<br>
> > > it, so apparently that isn't a big enough lever to get things moving<br>
> > > anyway. :-/<br>
> > <br>
> > using osc diretly i dont think the slowness is really perceptable from a human<br>
> > stand point but it adds up in a ci run. there are large problems to kill with gate<br>
> > slowness then fixing osc will solve be every little helps. i do agree however<br>
> > that the gage is not a big enough motivater for people to fix osc slowness as<br>
> > we can wait hours in some cases for jobs to start so 3 minutes is not really a consern<br>
> > form a latency perspective but if we saved 3 mins on every run that might<br>
> > in aggreaget reduce the latency problems we have.<br>
> <br>
> I find the slowness very noticeable in interactive use. It adds <br>
> something like 2 seconds to a basic call like image list that returns <br>
> almost instantly in the OSC interactive shell where there is no startup <br>
> overhead. From my performance days, any latency over 1 second was <br>
> considered unacceptable for an interactive call. The interactive shell <br>
> does help with that if I'm doing a bunch of calls in a row though.<br>
well that was kind of my point when we write sripts we invoke it over and over again.<br>
if i need to use osc to do lots of commands for some reason i generaly enter the interactive<br>
mode. the interactive mode already masks the pain so anytime it has bother me in the past<br>
i have just ended up using it instead. <br>
<br>
its been a long time since i looked at this but it think there were two reasons it is slow on startup.<br>
one is the need to get the token for each request and the other was related to the way we scan<br>
for plugins. i honestly dont know if either have imporved but the interactive shell elimiates both<br>
as issues.<br>
> <br>
> That said, you're right that 3 minutes multiplied by the number of jobs <br>
> we run per day is significant. Picking 1000 as a round number (and I'm <br>
> pretty sure we run a _lot_ more than that per day), a 3 minute decrease <br>
> in runtime per job would save about 50 hours of CI time in total. Small <br>
> things add up at scale. :-)<br>
yep it defintly does. <br>
> <br>
> > > <br>
> > > > <br>
> > > > > <br>
> > > > > > <br>
> > > > > > On 7/26/19 6:53 PM, Clark Boylan wrote:<br>
> > > > > > > Today I have been digging into devstack runtime costs to help Donny<br>
> > > > > > > Davis understand why tempest jobs sometimes timeout on the<br>
> > > > > > > FortNebula cloud. One thing I discovered was that the keystone user,<br>
> > > > > > > group, project, role, and domain setup [0] can take many minutes<br>
> > > > > > > [1][2] (in the examples here almost 5).<br>
> > > > > > > <br>
> > > > > > > I've rewritten create_keystone_accounts to be a python tool [3] and<br>
> > > > > > > get the runtime for that subset of setup from ~100s to ~9s [4].  I<br>
> > > > > > > imagine that if we applied this to the other create_X_accounts<br>
> > > > > > > functions we would see similar results.<br>
> > > > > > > <br>
> > > > > > > I think this is so much faster because we avoid repeated costs in<br>
> > > > > > > openstack client including: python process startup, pkg_resource<br>
> > > > > > > disk scanning to find entrypoints, and needing to convert names to<br>
> > > > > > > IDs via the API every time osc is run. Given my change shows this<br>
> > > > > > > can be so much quicker is there any interest in modifying devstack<br>
> > > > > > > to be faster here? And if so what do we think an appropriate<br>
> > > > > > > approach would be?<br>
> > > > > > > <br>
> > > > > > > [0]<br>
> > > > > > > <br>
> > <br>
> > <a href="https://opendev.org/openstack/devstack/src/commit/6aeaceb0c4ef078d028fb6605cac2a37444097d8/stack.sh#L1146-L1161" rel="noreferrer" target="_blank">https://opendev.org/openstack/devstack/src/commit/6aeaceb0c4ef078d028fb6605cac2a37444097d8/stack.sh#L1146-L1161</a><br>
> > > > > > >   <br>
> > > > > > > <br>
> > > > > > > [1]<br>
> > > > > > > <br>
<a href="http://logs.openstack.org/05/672805/4/check/tempest-full/14f3211/job-output.txt.gz#_2019-07-26_12_31_04_488228" rel="noreferrer" target="_blank">http://logs.openstack.org/05/672805/4/check/tempest-full/14f3211/job-output.txt.gz#_2019-07-26_12_31_04_488228</a><br>
> > > > > > >   <br>
> > > > > > > <br>
> > > > > > > [2]<br>
> > > > > > > <br>
<a href="http://logs.openstack.org/05/672805/4/check/tempest-full/14f3211/job-output.txt.gz#_2019-07-26_12_35_53_445059" rel="noreferrer" target="_blank">http://logs.openstack.org/05/672805/4/check/tempest-full/14f3211/job-output.txt.gz#_2019-07-26_12_35_53_445059</a><br>
> > > > > > >   <br>
> > > > > > > <br>
> > > > > > > [3] <a href="https://review.opendev.org/#/c/673108/" rel="noreferrer" target="_blank">https://review.opendev.org/#/c/673108/</a><br>
> > > > > > > [4]<br>
> > > > > > > <br>
> > <br>
> > <a href="http://logs.openstack.org/08/673108/6/check/devstack-xenial/a4107d0/job-output.txt.gz#_2019-07-26_23_18_37_211013" rel="noreferrer" target="_blank">http://logs.openstack.org/08/673108/6/check/devstack-xenial/a4107d0/job-output.txt.gz#_2019-07-26_23_18_37_211013</a><br>
> > > > > > >   <br>
> > > > > > > <br>
> > > > > > > <br>
> > > > > > > Note the jobs compared above all ran on rax-dfw.<br>
> > > > > > > <br>
> > > > > > > Clark<br>
> > > > > > > <br>
> > > > > > <br>
> > > > > > <br>
> > > <br>
> > > <br>
> > <br>
> > <br>
> <br>
> <br>
<br>
<br>
</blockquote></div>