Monday, 2024-06-10

*** ykarel_ is now known as ykarel07:01
*** haleyb|out is now known as haleyb14:51
sean-k-mooneyhi folks i know we can query logs viw opensearch like this https://tinyurl.com/35dfcfcy17:41
sean-k-mooneyor we can ask zuul of the buidl history like this https://zuul.openstack.org/builds?job_name=tempest-integrated-compute&result=TIMED_OUT&skip=017:41
sean-k-mooneybut is there a way we can get the average runtime of a job per provider17:42
sean-k-mooneylooking at the opensearch results it looks like almost all of the timeoute for tempest-integrated-compute are rax space providers17:43
sean-k-mooneyso im trying to fiture out if the successful runs are typeically slower on rax vs other providers and if so by how much17:43
clarkbwith the old elasticsearch system we queried the log info for timing and then aggregated by region. Not sure if still doable17:44
sean-k-mooneylook like the build times api does not actully work 17:50
sean-k-mooneycurl -X GET "https://zuul.openstack.org/api/tenant/{tenant_name}/build-times" -H  "accept: */*"17:50
sean-k-mooneyit proably would not give me the info i want anyway17:51
clarkbsean-k-mooney: there is a test for build-times so ti should work17:51
sean-k-mooneywell its responding with a html snipit17:51
sean-k-mooneythat does not render17:51
sean-k-mooneyi get this https://termbin.com/rvs317:52
clarkbyou probably need to send the header for json not */*17:52
clarkbya @cherrypy.tools.json_out(content_type='application/json; charset=utf-8') decorates the build_times method17:52
sean-k-mooneyperhaps but thats also what i get back form the openapi client in my broser17:52
sean-k-mooneyi.e. the one here https://zuul.openstack.org/openapi17:53
clarkbyou also need to replace tenant_name with a valid tenant name17:53
clarkbbut this is tested it should work17:53
sean-k-mooneyyep im using openstack17:53
clarkbI managed to get an empty reply from server. I wonder if it timed out17:56
sean-k-mooneyits fine as i said this proably wont have the provider info in the resonce anyway17:57
clarkbno it would not include thati nfo17:57
sean-k-mooneywhat im trying to determin is it reasonab to increase the time out form 2 hours to 2.5 hours to accomadate the ocational slow node on rax17:58
sean-k-mooneyand to determin that i kind of need ot know what the expect time is for succesful runs per provider17:59
sean-k-mooneyif we see a trend that rax is typically slower then the rest then that supprot exending it. if however its typicall yin the same range perhaps we should expore somethign else18:00
clarkbya I would look at the records in elasticsearch18:01
clarkbyou should be able to collect runtime info out of the log files matching on a specific logline. Then collect them for the regions you care about and dump into a csv file for processing18:02
sean-k-mooneythe only problem with this is we dont have the tiem a job took to execute in elasticsearch18:02
clarkbno but you have the tox/stestr runtime and also info if it timed out18:02
clarkbyou also have the devstack runtimes18:02
opendevreviewJames Parker proposed openstack/whitebox-tempest-plugin master: Use sudo when gather compute id information  https://review.opendev.org/c/openstack/whitebox-tempest-plugin/+/92169918:02
sean-k-mooneythats fir we could look at the tempest execution time an ddevstack time for the succsseful runs18:03
sean-k-mooneyand use that as a proxy for total job time18:03
clarkbsean-k-mooney: I checked with corvus and he says the build-times stuff is still a bit of a work in progress. It was added to support https://review.opendev.org/c/zuul/zuul/+/899767 which hasn't landed yet and the queries involved are optimized for what that page does18:03
sean-k-mooneyya i noticed the api docs said "reposce is not docuemtned yet" 18:04
sean-k-mooneyso i assuemd it was not ready for prime time18:04
sean-k-mooneyoh interesting18:05
sean-k-mooneyya that page sound useful18:05
sean-k-mooneyits just a shame we still wont have the rejoin info form the jobs18:05
sean-k-mooneyits in the zuul inventory 18:05
clarkbrejoin info?18:05
sean-k-mooneybut the region is just not a zull job output so presumable 18:06
sean-k-mooneynot quieryable18:06
sean-k-mooneythe provider18:06
sean-k-mooneyi just spell thing horribly :)18:06
clarkboh region. Ya the reason for that is all of that info is on the nodepool side of things so doesn't end up in zuul's db. There is effort underway to move nodepool into zuul as a zuul component and then we could probably collect that data more easily18:06
sean-k-mooneywell its also in the inventory that zuul creats18:07
sean-k-mooneybut the inventory is not really part fo any zuul api18:07
sean-k-mooneyand the filed we are using is likely custom to our deployment18:07
sean-k-mooneyok so this kind of works https://tinyurl.com/996xk2s218:11
sean-k-mooneythats all the devstack timing form the devstack summary18:11
opendevreviewJames Parker proposed openstack/whitebox-tempest-plugin master: Use sudo when gather compute id information  https://review.opendev.org/c/openstack/whitebox-tempest-plugin/+/92169918:15
opendevreviewGoutham Pacha Ravi proposed openstack/devstack-plugin-ceph master: Standalone nfs-ganesha with cephadm deployment  https://review.opendev.org/c/openstack/devstack-plugin-ceph/+/91521223:58
opendevreviewGoutham Pacha Ravi proposed openstack/devstack-plugin-ceph master: Delete package-based-installation test jobs  https://review.opendev.org/c/openstack/devstack-plugin-ceph/+/91895123:58

Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!