Monday, 2026-03-23

*** ykarel__ is now known as ykarel04:36
*** zseguin_ is now known as zseguin06:13
*** gibi_ is now known as gibi08:12
opendevreviewBalazs Gibizer proposed openstack/nova master: Move py312-threading to py313  https://review.opendev.org/c/openstack/nova/+/98045812:51
nicolairuckelDo I understand it correctly, that this is done? https://blueprints.launchpad.net/nova/+spec/vtpm-live-migration14:22
nicolairuckelAnd all patches from here that are merged should belong to the implementation? https://review.opendev.org/q/topic:%22bp/vtpm-live-migration%2214:22
dansmithyes, and "should"14:26
nicolairuckelthanks :)14:36
Ugglamelwitt, gmaan, please can you review again https://review.opendev.org/c/openstack/nova/+/981085 it should not take long.14:55
UgglaUpstream meeting in ~1h.15:06
opendevreviewMerged openstack/nova stable/2026.1: Fix Flamingo version in qemu matrix.  https://review.opendev.org/c/openstack/nova/+/98108515:21
Uggla#startmeeting nova16:00
opendevmeetMeeting started Mon Mar 23 16:00:31 2026 UTC and is due to finish in 60 minutes.  The chair is Uggla. Information about MeetBot at http://wiki.debian.org/MeetBot.16:00
opendevmeetUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.16:00
opendevmeetThe meeting name has been set to 'nova'16:00
gibio/16:00
UgglaHello everyone16:00
nicolairuckelo/16:01
fwieselo/16:01
lajoskatonao/16:02
UgglaLet's start16:03
Uggla#topic Bugs (stuck/critical) 16:03
Uggla#info No Critical bug16:03
bauzaso/16:04
Uggla#topic Gate status 16:04
elodilleso/16:04
Uggla#link https://bugs.launchpad.net/nova/+bugs?field.tag=gate-failure Nova gate bugs16:04
Uggla#link https://etherpad.opendev.org/p/nova-ci-failures-minimal16:04
Uggla#link https://zuul.openstack.org/builds?project=openstack%2Fnova&project=openstack%2Fplacement&branch=stable%2F*&branch=master&pipeline=periodic-weekly&skip=0 Nova&Placement periodic jobs status16:05
Uggla#info Please look at the gate failures and file a bug report with the gate-failure tag.16:05
Uggla#info Please try to provide a meaningful comment when you recheck16:05
UgglaTBH I have not looked at the status pages. Anything wrong with the gate ?16:05
sean-k-mooneyo/16:06
Ugglaseems not so moving on16:07
Uggla#topic Release Planning 16:07
Uggla#link https://releases.openstack.org/gazpacho/schedule.html16:07
Uggla#info Nova deadlines are set in the above schedule16:08
Uggla#info PTG etherpad for 2026.2 is available: https://etherpad.opendev.org/p/nova-2026.2-ptg16:08
Uggla#info This is a "work in progress document", but you can enter you topics at the bottom of the document16:08
UgglaI have seen gibi already entered something about eventlet, so thanks16:08
Uggla#info This week is final RCs, release should happen next week.16:09
Uggla#topic Review priorities16:10
Uggla#link https://etherpad.opendev.org/p/nova-2026.1-status16:10
UgglaI will open the new doc for 2026.2 this week.16:10
UgglaThere is 979301: Update min support for Hibiscus | https://review.opendev.org/c/openstack/nova/+/979301 pending waiting for grenade update.16:12
UgglaThen we should be completely ok for 2026.116:12
Uggla#topic Stable Branches 16:13
* Uggla giving the mic to elodilles16:13
elodillesthanks16:13
elodilles#info nova stable gates should be OK16:13
elodilles#info placement and osc-placement have blocked stable gates, fixes need stable cores review (see: https://review.opendev.org/q/topic:pin-setuptools-81-docs and https://review.opendev.org/q/topic:pin-setuptools-81-via-virtualenv-pkg-resources)16:13
elodilles#info stable branch status / gate failures tracking etherpad: https://etherpad.opendev.org/p/nova-stable-branch-ci16:14
elodillesand that's all from me about stable16:14
* elodilles is passing back the mic16:14
Ugglathanks elodilles, that looks in a good shape.16:14
Uggla#topic vmwareapi 3rd-party CI efforts Highlights16:14
Ugglafwiesel anything for us ?16:15
fwieselno updates from my side 16:15
Ugglaok thx16:15
Uggla#topic Gibi's news about eventlet removal16:15
gibio/16:15
gibitwo things16:15
* Uggla I know about a blogpost, but giving the mic to gibi16:15
gibifwiesel: could you please take a look at the comment https://review.opendev.org/c/openstack/nova/+/973468/22#message-a3e61c625edd2a7a737962c5ea9913caa335d5fc it is about troubleshooting vmware CI with native threading16:16
fwieselgibi: Sure, I'll check.16:16
gibithanks16:16
gibiand the other is what Uggla hinted at. There is finally a new blogpost about Eventlet16:16
gibihttps://gibizer.github.io/posts/Eventlet-Removal-Gazpacho/16:16
Uggla👍16:17
gibiand that is it from me16:17
Ugglathanks gibi.16:17
Uggla#topic Nova using openstack sdk for neutron16:18
* Uggla giving the mic to lajoskatona16:18
lajoskatonao/ thanks16:18
lajoskatonaI pushed a new ps for security-groups: https://review.opendev.org/c/openstack/nova/+/98114116:18
lajoskatonaand I polished the older patches also to make them ready for review for early H16:19
lajoskatonaThe security-group one is wip as it seems I still break something :-)16:19
lajoskatonaAfter that I hope I can check what remains, that is for sure the port-binding API and some other small things, so that will come soon I hope16:20
lajoskatonathat's it for the SDK work16:20
sean-k-mooneyack. so its breaking in tempest but not in the unit/fucntional tests16:21
lajoskatonaexactly, so I have to read more logs16:21
Ugglaoh not cool.16:22
lajoskatonalife, if you touch something you break something :-(16:23
Ugglasometimes.16:24
Uggla#topic Open discussion 16:24
UgglaI forget to say something in review priorities. 16:25
Ugglahttps://review.opendev.org/q/topic:%22bp/generalize-sev-code%22 looks good to me. Except latest patch we agreed to remove from this serie.16:25
Ugglagibi from you point of view anything still not ok with the serie ?16:26
gibiI have to go back to that series16:26
gibiI lost context over last week16:26
Ugglathanks gibi, it will be great to merge that before starting new CC stuffs.16:27
gibiI had some negative feedback before but I guess that was addressed in the meantime16:27
gibiUggla: sure, but that also needs two cores ;)16:28
Ugglagibi, yes I have not noticed remaining open things.16:28
UgglaI know, bauzas maybe ?16:28
* bauzas is in a convo somewhere else16:29
bauzasOK, drop me as a reviewer16:29
UgglaOK done for this one.16:30
UgglaSecond, it seems I will be PTL again for H cycle.16:30
gibiUggla: thanks for your continued service16:31
elodillesyepp, thanks Uggla \o/16:31
Ugglathank you.16:31
UgglaThird point, we may have 2 x potential new slots for upstream bug triage.16:32
UgglaIt is not settled at the moment. I need to think about how we will organize that.16:33
UgglaI will keep you posted via the ML16:34
Ugglathat's all for me. Does anyone else want to discuss something ?16:35
sean-k-mooneyam more a quick fyi16:36
Ugglasure16:36
sean-k-mooneyso JayF raised a long stanidng issue with the ironic driver (startup time)16:36
sean-k-mooneyi pent a few hourse playing aroudn with https://review.opendev.org/q/topic:%22startup-time%2216:37
sean-k-mooneybaisly i create a poc of a simulator to messuer the perfoamcne of it as we scaled out ironic nodes16:37
sean-k-mooneythis uses our functional tests infrastucer and then i ran some profileing of the starut and had ai analise it16:38
sean-k-mooneyso i just wanted to share that as it found we are don an quadtaric deep copy of the resouce providers16:38
* JayF owes you a look on that chain but hasn't gotten there yet, apologies (not that my reviews are likely to be useful on the deep-in-nova stuff)16:38
sean-k-mooneyi dont know if this tool could be useful for other things liek similarting large env for schduler fileter or eventlet debuging16:39
sean-k-mooneybtu i just wanted to share that it exists as a review incase anyone found it interesting16:39
sean-k-mooneythe code quality/style is not what i woudl normally do16:39
sean-k-mooneysince this was just a quick poc16:39
sean-k-mooneybut it did produce some interesting results so ya that was all i had16:40
gibisean-k-mooney: does the deep-copy expensive due to multiple compute nodes per compute host?16:40
sean-k-mooneyhttps://review.opendev.org/c/openstack/nova/+/980679 and https://review.opendev.org/c/openstack/nova/+/980676/116:40
sean-k-mooneygibi: yep16:40
sean-k-mooneyso for 1000 noes we copery the resouce provider for the first one 999 times i blieve16:40
gibiohh I see why that is bad :) 16:41
dansmiththis totally doesn't surprise me :)16:41
Uggla(OO°16:41
Uggla(OO)16:41
sean-k-mooneyanyway im not sayign the poc patches are correct 16:41
dansmithlike I bet we probably have some things like that in runtime code too16:41
sean-k-mooneybut locally they do sped thing up alot16:41
sean-k-mooneyya so this deepcopy is in get_provider_tree_and_ensure_root16:42
gibisean-k-mooney: my only question is if this is the real bottleneck, ie the code, or is there any nova-ironic interaction at startup that is inherently slow due to network?16:42
gibiI imagine 1000 tree memcopy is still faster than 1000 network call to ironic16:43
sean-k-mooneyon my laptop the delta between the first patch and last goes form 2 and ahalf minute sdown to 40 ish seconds16:43
sean-k-mooneyi didnt try tweakign the latency ineject for the api calls16:43
sean-k-mooneybut the similater in thory can add in some it defautl to 0 for the get node call at the momemnt16:43
gibiI though you have it in funct test, I'm sure that mock ironic API calls16:44
dansmithsean-k-mooney: and lots of cpu usage I guess?16:44
sean-k-mooneyyep as i said i only spent a few hour on this at the weekend but i wanted to see if we coudl guest some emperical data16:44
gibianyhow. Improvement is good. Question remains if we improved the critical path or not16:44
sean-k-mooneybefore the ironic cross project session16:44
sean-k-mooneythe other atpch that helps is https://review.opendev.org/c/openstack/nova/+/980679/116:45
sean-k-mooneythat kicks out the per node operation into a thread pool16:45
dansmithwell, and if we improved it without introducing other issues (like the cache patch seems the easiest, but as <human> points out it may be problematic)16:45
sean-k-mooneyhttps://review.opendev.org/c/openstack/nova/+/980680/116:45
sean-k-mooneyis a basi update to the reprot before/after the sersise but as i said i have not fully validate this as correct16:46
sean-k-mooneyits easy to make thing fast if correctness is not a requirement16:46
dansmithand honestly two minutes to start up with lots of nodes may not be unreasonable,  but certainly sucks if we can avoid it (especially if it's just burning cpu time copying stuff)16:46
sean-k-mooneydansmith: so on real ironci system its 15+ minutes16:46
dansmithyeah, uncool :)16:46
sean-k-mooneybased on the commit messge i lied  N=1000: 42.1 s (42.1 ms/node)  — was 4 min 4 s (244 ms/node)16:47
sean-k-mooneyso it was 4 minutes even without any network overhead16:47
sean-k-mooneyi will also note the bigest boteel neck on the 1000 node case was in placmenet16:47
sean-k-mooneyin the jsonschema validation16:47
sean-k-mooneybut that partly an artifact fo me using the palcement fixture16:47
dansmithI think we can also put #squarepegroundhole on some of this16:48
sean-k-mooneyanyway i just wanted to share one of the experiemts i did. im not sure if we coudl eveolve this simulator into a gerneicly useful perf tool16:49
sean-k-mooneydansmith: you had asked about a schduer simultor in the past so this might be a foundation to build that if we had time 16:49
Uggladansmith #squarepegroundhole what's that ?16:49
dansmithI guess maybe I'd like to have JayF (a mere human) look over this for ironic gotchas before we look too deep at the other things16:49
dansmithsean-k-mooney: yep, for sure16:49
JayFthe biggest issue is that it's dangerous to heavily lean on a cache16:50
dansmithUggla: ironic as a driver in nova is a square peg in a round hole (doesn't fit very well and has lots of ironic-specific issues like this)16:50
JayFbecause it completely breaks use cases where "node completes cleaning -> immediate re-deploy" which while it's not a very openstack-y use case, is very common16:50
sean-k-mooneyUggla: the reall issues is the compute agent was desgisn to have 1 pre compute node. the ironic driver has 1 agent for 1000s16:50
dansmiththis ^16:50
JayFwe'd need ironic to close that loop on more of an event-driven basis vs a poll to fix that concern before relying more heabily on cache16:50
JayFadmittedly my initial email was written assuming "ironic updates more stuff about ironic nodes" may be the path, I didn't expect sean-k-mooney to find low-hanging-fruit like he has16:51
sean-k-mooneyJayF: ya i saw your coment on the cach. i think we shoudl actully start lookign at riping out the hasring stuff16:51
sean-k-mooneybut also have a wider converation on this in general16:51
JayFeven just if we put in knobs to let operators make the tradeoff, it might help, idk16:52
JayFI'll ensure I review those before the cross-project session16:52
JayFif a sync between just us two to refine before PTG is valuable, we can do that too16:52
sean-k-mooneyya perhaps. the one caveat ill say is im not activly working on this16:52
sean-k-mooneybut you peaked my interest enouch to see if there was anythign obviously wrong16:53
sean-k-mooneyor simple improvemtn we coudl make 16:53
JayFIt's a major issue for Ironic/Nova users; which are 25% of nova users per the survey :) hopefully we can catch the eyes of someone who has expertise, even just to lay the path out for me and/or my team (cid or clif) to implement16:54
sean-k-mooneyJayF: i can chat to you after the meetign more if you like but it might be interestign to see if we could perhaps replciate this in devstack with the ironic fake driver16:54
JayFyeah, that sounds like a good path16:55
JayFand I've wanted to make ironic easier to hook up in devstack with fake driver16:55
sean-k-mooneyi.e. to see if the imovpments in this emulated env traslate to a real env16:55
JayFmaybe I'll spike on that between now:ptg16:55
sean-k-mooneyUggla: sorry that took more time then i was planning but i think this has been productive16:56
JayFwe should take Uggla to "why Ironic driver is awesome and terrible 101" some day, I think :P 16:56
UgglaJayF sure16:56
dansmithlet him enjoy life, gawd16:56
dansmiththat's like explaining santa16:57
UgglaAre we good ?16:57
JayF"And here's _tooth_fairy()"16:57
JayFyes, ty Uggla :)16:57
UgglaAnything else ?16:57
Ugglaseems not.16:58
dansmithJayF: wait, what's your point about the tooth fairy? If you have  a contact, I'm still waiting for $1016:58
UgglaQuick update on bug scrubbing because we are at he top of the hour.16:58
Uggla#topic Bug scrubbing 16:58
Uggla#info up to 199 (-7)16:58
JayFdansmith: I saw her walking out of "Budget Dentures". Scandalous! ;) 16:59
dansmithlol16:59
UgglaI manage to go down 200.16:59
Uggla#link: https://etherpad.opendev.org/p/nova-bug-triage-roster16:59
Uggla#link: https://truc.uggla.fr/  if you want to see the trend.16:59
UgglaJayF, dansmith, can tooth fairy do something for bugs ?17:00
JayFIf she is a metaphor for the Ironic driver, she can create them ;) 17:01
Uggla:)17:01
UgglaTime to close.17:01
Ugglathanks for joining this meeting. Have a nice day/evening and see you next week.17:02
gibio/17:02
Uggla#endmeeting17:02
opendevmeetMeeting ended Mon Mar 23 17:02:17 2026 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)17:02
opendevmeetMinutes:        https://meetings.opendev.org/meetings/nova/2026/nova.2026-03-23-16.00.html17:02
opendevmeetMinutes (text): https://meetings.opendev.org/meetings/nova/2026/nova.2026-03-23-16.00.txt17:02
opendevmeetLog:            https://meetings.opendev.org/meetings/nova/2026/nova.2026-03-23-16.00.log.html17:02
elodillessame to you, thanks o/17:02
lajoskatonao/17:02
sean-k-mooneymelwitt: thanks for taking a look at https://review.opendev.org/c/openstack/nova/+/975872/518:27
sean-k-mooneymelwitt: gibi  do you thinks we could try and get the repoducer patch merged in the next few days https://review.opendev.org/c/openstack/nova/+/975859/4 while we dicuss the fix in https://review.opendev.org/c/openstack/nova/+/97587218:28
sean-k-mooneyit woudl be nice to make some progress on this again. im hoping to complete that bug work in the next week or two 18:29
melwittsean-k-mooney: ok yeah let me focus on that one then, I had started with the fix (obviously)18:29
sean-k-mooneymainly to avoid having to load context on this over and over again18:29
sean-k-mooneymelwitt: ill definally look into your feedback on teh fix too18:29
sean-k-mooneyjust want to see if we can make incremental progress18:30
gibisean-k-mooney: I don't immediately have capacity for that patch. Please ping me in couple of days18:31
melwittsean-k-mooney: sure. thanks for letting me know18:31
sean-k-mooneymelwitt: since i started wroking on this i have had time to look at the cybrog quota code and foudn its entrily non fucntional https://bugs.launchpad.net/openstack-cyborg/+bug/214394318:31
sean-k-mooneygibi: ack will do 18:31
melwittsean-k-mooney: wow that's wild18:32
sean-k-mooneyi have a writeups attached https://launchpadlibrarian.net/851194002/quota-system.md but tldr is the safolding for qutas was built in the v1 api but never ported to v218:32
sean-k-mooneyat this point i think im just oging to rip it out since it does not work and if we need to have native supprot in cybrog indepent of th enova fix go staight to unified limits 18:33
melwittyeah I think that's probably the best move to just go straight to unified limits18:35
melwittif fixing the current thing is not trivial 18:35
sean-k-mooneywell its worked for 10 months and has been broken since 201918:35
sean-k-mooneyso its not so much how hard is fixing it its is it worth addign a seperate quota api to cyborg at all at this point if we can just use unified limits18:36
sean-k-mooneythe entiretly of the v1 api was deleted years ago and it never existed in v218:36
dansmithunified limits is easy that way.. saves a lot of api effort18:36
melwittsean-k-mooney: adding a separate API = not trivial :) so yeah18:37
sean-k-mooneyin cybrog qutoa was also only configurable via config before when it did work so there is also no prior art to revive18:37
dansmiththat's like glance18:38
dansmithlike glance _was_ before unified limits, I should say18:38
sean-k-mooneyack18:38
dansmitheven if you had prior art, unified limits instantly makes you more modern and compatible with the way the other projects are going, IMHO, so that's a reason right there18:39
sean-k-mooneyright now im not fucosing on cybrog as a standalone service "without nova" so if we fix the enfocement on the nova side then that closes the gap although at some point i shoudl add quta checks indepenet of nova spawn/resize code before we add attach/detach supprot18:40
sean-k-mooneyanyway out of scope of nova but this will eventually get doen after the other higher priorty items18:41
sean-k-mooneyARQ binding is when a resouce is actully assigne dto an instnace so that is where we should be checking to prevent over quota usage longterm.18:42
sean-k-mooneyi.e form parallel nova instance cretes18:43
opendevreviewMerged openstack/nova master: Move py312-threading to py313  https://review.opendev.org/c/openstack/nova/+/98045820:06

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