Posted	Nick	Remark
#openstack-nova - 2026-03-23
16:10:31	Uggla	#link https://etherpad.opendev.org/p/nova-2026.1-status
16:10:55	Uggla	I will open the new doc for 2026.2 this week.
16:12:03	Uggla	There is 979301: Update min support for Hibiscus | https://review.opendev.org/c/openstack/nova/+/979301 pending waiting for grenade update.
16:12:30	Uggla	Then we should be completely ok for 2026.1
16:13:26	Uggla	#topic Stable Branches
16:13:43	elodilles	thanks
16:13:47	elodilles	#info nova stable gates should be OK
16:13:56	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:14:04	elodilles	#info stable branch status / gate failures tracking etherpad: https://etherpad.opendev.org/p/nova-stable-branch-ci
16:14:13	elodilles	and that's all from me about stable
16:14:43	Uggla	thanks elodilles, that looks in a good shape.
16:14:57	Uggla	#topic vmwareapi 3rd-party CI efforts Highlights
16:15:05	Uggla	fwiesel anything for us ?
16:15:12	fwiesel	no updates from my side
16:15:19	Uggla	ok thx
16:15:32	Uggla	#topic Gibi's news about eventlet removal
16:15:41	gibi	o/
16:15:44	gibi	two things
16:16:09	gibi	fwiesel: 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 threading
16:16:21	fwiesel	gibi: Sure, I'll check.
16:16:26	gibi	thanks
16:16:50	gibi	and the other is what Uggla hinted at. There is finally a new blogpost about Eventlet
16:16:53	gibi	https://gibizer.github.io/posts/Eventlet-Removal-Gazpacho/
16:17:13	Uggla	👍
16:17:34	gibi	and that is it from me
16:17:46	Uggla	thanks gibi.
16:18:06	Uggla	#topic Nova using openstack sdk for neutron
16:18:28	lajoskatona	o/ thanks
16:18:40	lajoskatona	I pushed a new ps for security-groups: https://review.opendev.org/c/openstack/nova/+/981141
16:19:06	lajoskatona	and I polished the older patches also to make them ready for review for early H
16:19:34	lajoskatona	The security-group one is wip as it seems I still break something :-)
16:20:12	lajoskatona	After 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 hope
16:20:34	lajoskatona	that's it for the SDK work
16:21:01	sean-k-mooney	ack. so its breaking in tempest but not in the unit/fucntional tests
16:21:32	lajoskatona	exactly, so I have to read more logs
16:22:59	Uggla	oh not cool.
16:23:52	lajoskatona	life, if you touch something you break something :-(
16:24:01	Uggla	sometimes.
16:24:32	Uggla	#topic Open discussion
16:25:13	Uggla	I forget to say something in review priorities.
16:25:55	Uggla	https://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:26:25	Uggla	gibi from you point of view anything still not ok with the serie ?
16:26:26	gibi	I have to go back to that series
16:26:34	gibi	I lost context over last week
16:27:35	Uggla	thanks gibi, it will be great to merge that before starting new CC stuffs.
16:27:38	gibi	I had some negative feedback before but I guess that was addressed in the meantime
16:28:01	gibi	Uggla: sure, but that also needs two cores ;)
16:28:20	Uggla	gibi, yes I have not noticed remaining open things.
16:28:51	Uggla	I know, bauzas maybe ?
16:29:38	bauzas	OK, drop me as a reviewer
16:30:13	Uggla	OK done for this one.
16:30:45	Uggla	Second, it seems I will be PTL again for H cycle.
16:31:01	gibi	Uggla: thanks for your continued service
16:31:27	elodilles	yepp, thanks Uggla \o/
16:31:51	Uggla	thank you.
16:32:50	Uggla	Third point, we may have 2 x potential new slots for upstream bug triage.
16:33:46	Uggla	It is not settled at the moment. I need to think about how we will organize that.
16:34:17	Uggla	I will keep you posted via the ML
16:35:11	Uggla	that's all for me. Does anyone else want to discuss something ?
16:36:11	sean-k-mooney	am more a quick fyi
16:36:18	Uggla	sure
16:36:48	sean-k-mooney	so JayF raised a long stanidng issue with the ironic driver (startup time)
16:37:03	sean-k-mooney	i pent a few hourse playing aroudn with https://review.opendev.org/q/topic:%22startup-time%22
16:37:32	sean-k-mooney	baisly i create a poc of a simulator to messuer the perfoamcne of it as we scaled out ironic nodes
16:38:06	sean-k-mooney	this uses our functional tests infrastucer and then i ran some profileing of the starut and had ai analise it
16:38:38	sean-k-mooney	so i just wanted to share that as it found we are don an quadtaric deep copy of the resouce providers
16:39:10	sean-k-mooney	i dont know if this tool could be useful for other things liek similarting large env for schduler fileter or eventlet debuging
16:39:27	sean-k-mooney	btu i just wanted to share that it exists as a review incase anyone found it interesting
16:39:46	sean-k-mooney	the code quality/style is not what i woudl normally do
16:39:51	sean-k-mooney	since this was just a quick poc
16:40:05	sean-k-mooney	but it did produce some interesting results so ya that was all i had
16:40:21	gibi	sean-k-mooney: does the deep-copy expensive due to multiple compute nodes per compute host?
16:40:25	sean-k-mooney	https://review.opendev.org/c/openstack/nova/+/980679 and https://review.opendev.org/c/openstack/nova/+/980676/1
16:40:30	sean-k-mooney	gibi: yep
16:40:48	sean-k-mooney	so for 1000 noes we copery the resouce provider for the first one 999 times i blieve
16:41:00	gibi	ohh I see why that is bad :)
16:41:15	dansmith	this totally doesn't surprise me :)
16:41:24	Uggla	(OO°
16:41:28	Uggla	(OO)
16:41:37	sean-k-mooney	anyway im not sayign the poc patches are correct
16:41:40	dansmith	like I bet we probably have some things like that in runtime code too
16:41:43	sean-k-mooney	but locally they do sped thing up alot
16:42:16	sean-k-mooney	ya so this deepcopy is in get_provider_tree_and_ensure_root
16:42:25	gibi	sean-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:43:08	gibi	I imagine 1000 tree memcopy is still faster than 1000 network call to ironic
16:43:18	sean-k-mooney	on my laptop the delta between the first patch and last goes form 2 and ahalf minute sdown to 40 ish seconds
16:43:31	sean-k-mooney	i didnt try tweakign the latency ineject for the api calls
16:43:51	sean-k-mooney	but the similater in thory can add in some it defautl to 0 for the get node call at the momemnt
16:44:07	gibi	I though you have it in funct test, I'm sure that mock ironic API calls
16:44:17	dansmith	sean-k-mooney: and lots of cpu usage I guess?
16:44:44	sean-k-mooney	yep 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 data
16:44:46	gibi	anyhow. Improvement is good. Question remains if we improved the critical path or not
16:44:54	sean-k-mooney	before the ironic cross project session
16:45:14	sean-k-mooney	the other atpch that helps is https://review.opendev.org/c/openstack/nova/+/980679/1
16:45:26	sean-k-mooney	that kicks out the per node operation into a thread pool
16:45:35	dansmith	well, 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:39	sean-k-mooney	https://review.opendev.org/c/openstack/nova/+/980680/1
16:46:00	sean-k-mooney	is a basi update to the reprot before/after the sersise but as i said i have not fully validate this as correct
16:46:09	sean-k-mooney	its easy to make thing fast if correctness is not a requirement
16:46:21	dansmith	and 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)

Earlier   Later