Posted	Nick	Remark
#openstack-nova - 2025-07-22
15:29:22	gibi	bauzas: I can run it but I will run it with a quick "does anybody has anything to raise to the team" style
15:29:37	gibi	and if silence then I will not iterate the agenda
15:33:04	jssfr	I have two questions, which may be answerable outside the team meeting: (a) the AMD SEV-ES patches are at the top of the review list, is there anything we as a contributing company (not to that patchset specifically, but in general) can do to help?
15:33:37	jssfr	(b) I pointed out the loss of vTPM state upon start/stop of an instance the other day and I have something which resembles a patch. Do I need to file an issue first, or is it enough if I submit a patchset to gerrit?
15:34:00	bauzas	thanks gibi
15:34:12	dansmith	jssfr: B will probably warrant a spec
15:34:35	gibi	jssfr: a) honestly I don't have a good answer for that. Uggla noted that it is ready for review and even pinged us downstream about it. I'm think most of our cores are busy with other review promises. Keep pinging us (I know it is tiring)
15:34:38	jssfr	dansmith, uh-uh, how so?
15:35:08	jssfr	gibi, oh I am fine with pinging, I just don't want to come off as annoying. :-)
15:35:13	dansmith	jssfr: IIRC there are some gotchas around both vTPM and NVRAM state that cause us to dump them at certain times, and there's an overlap with the planned/ongoing vTPM live migration work
15:35:40	jssfr	okay, that's good to know. fwiw, the patch is basically just passing VIR_DOMAIN_UNDEFINE_KEEP_TPM if destroy_secrets == False, which seems logical enough to me.
15:36:06	jssfr	maybe it makes sense to submit the patch first and then you can still tell me it needs a spec :-).
15:36:22	jssfr	(always easier to talk about an actual diff than about a hypothetical one, in my experience)
15:36:27	gibi	jssfr: you need to find the balance of being seen but not beeing annoying :) Anyhow I can tell you we are aware of your patches waiting for review
15:36:39	jssfr	(not my patches, but thanks :))
15:36:41	dansmith	jssfr: there's no reason not to push the code. ever.
15:37:16	gibi	(don't push a code if you feel it is a security bug :)
15:37:27	dansmith	gibi: dammit gibi :)
15:37:59	jssfr	fair point :D
15:38:03	gibi	otherwise I'm fully agree with dansmith of course :)
15:38:07	jssfr	thanks for the feedback :)
16:00:47	gibi	#startmeeting nova
16:00:47	opendevmeet	Meeting started Tue Jul 22 16:00:47 2025 UTC and is due to finish in 60 minutes. The chair is gibi. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:47	opendevmeet	Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:47	opendevmeet	The meeting name has been set to 'nova'
16:00:54	fwiesel	o/
16:01:08	sp-bmilanov	o/
16:01:31	dansmith	o/
16:01:33	gibi	Uggla is on a well deserved PTO and his stand in cannot be here today. So I agreed to run something like a nova meeting but I'm not prepared.
16:02:13	gibi	lets wait a bit to see if other cores join but so far we are low on quorum
16:02:19	elodilles	o/
16:02:42	gmaan	o/
16:03:09	gibi	(an I have a dinner invitation that helps me prioritize)
16:03:35	gibi	lets get roling
16:03:36	gibi	#topic Bugs (stuck/critical)
16:03:50	gibi	any fresh critical bug we need to look at?
16:04:28	gibi	the on one the agenda https://bugs.launchpad.net/nova/+bug/2116852 is not critical any more as we disable the single tempest test that caused the blockade
16:05:05	gibi	I filed the upstream bug to Ceph https://tracker.ceph.com/issues/72203 they are silent so far. I have way to ping them downstream which I will use next week if no reaction on the upstream tracker
16:05:18	gibi	any other critical adjacent bug?
16:05:45	gibi	#topic Gate status
16:05:51	gibi	any issues with our gate?
16:06:01	gibi	I'm not tracking anything major on my side at least
16:06:45	gibi	#topic tempest-with-latest-microversion job status
16:06:58	gibi	it is red
16:07:01	gibi	:)
16:07:14	gibi	- Failed: 27
16:07:28	gibi	I have no other info. Anybody wants to comment?
16:07:32	gmaan	yeah, my last fix is still not merged but that make 6 more test green and 21 still failing
16:07:42	gmaan	I did not get chance to continue this one.
16:07:48	gibi	gmaan: cool. Thanks
16:08:01	gibi	#topic Release Planning
16:08:05	gibi	#link https://releases.openstack.org/flamingo/schedule.html
16:08:17	gibi	anybody has any comment here?
16:08:54	gibi	#topic Review priorities
16:08:58	gibi	#link https://etherpad.opendev.org/p/nova-2025.2-status
16:09:05	gibi	any comments?
16:09:44	gibi	#topic OpenAPI
16:09:47	gibi	#link: https://review.opendev.org/q/topic:%22openapi%22+(project:openstack/nova+OR+project:openstack/placement)+-status:merged+-status:abandoned
16:10:00	gibi	16 open patches mostly stuck on gate or waiting for rebase
16:10:24	gibi	any comments?
16:11:06	gibi	#topic Stable Branches
16:11:17	gibi	elodilles: give us what you have!
16:11:23	elodilles	ACK :)
16:11:36	elodilles	actually state is pretty same as last week
16:11:46	elodilles	stable branches seems healthy
16:11:59	elodilles	and stable releases are waiting for release liaisons
16:12:05	elodilles	gibi: back to you
16:12:51	gibi	who are our liaisons to ping?
16:13:14	elodilles	Uggla Amit and Sylvain
16:13:55	gibi	bauzas: ^^ auniyal ^^
16:14:02	gibi	please look at the stable release requests
16:14:17	gibi	#topic vmwareapi 3rd-party CI efforts Highlights
16:14:24	gibi	fwiesel: any news?
16:14:26	fwiesel	Hi, nothing from my side.
16:14:35	gibi	fwiesel: OK cool
16:14:39	gibi	#topic Gibi's news about eventlet removal.
16:14:44	gibi	hey thats me :)
16:15:17	gibi	we are slowly landing patches from the scheduler series
16:15:45	gibi	I got a nice set of reviews from bauzas on the doc patch. I have to go back there and touch up the doc
16:16:50	gibi	sambork's patch https://review.opendev.org/c/openstack/nova/+/949754 logic looks good to me but I found some extra cleanup pieces and a bit of test issues
16:17:35	gibi	and I'm following Dan's series starting https://review.opendev.org/c/openstack/nova/+/954990/4
16:18:16	gibi	I still have the intention to go back making our unit tests run with threading
16:18:19	gibi	that is it
16:18:31	gibi	#topic Open discussion
16:18:34	gibi	(sp-bmilanov) Bug #2092391: duplication instances when nova compute service restart: https://bugs.launchpad.net/nova/+bug/2092391
16:18:46	sp-bmilanov	hi :)
16:19:07	gibi	I guess this is a review request for https://review.opendev.org/c/openstack/nova/+/938223
16:19:10	gibi	am I correct?
16:19:16	sp-bmilanov	not exactly
16:19:21	gibi	ohh
16:19:25	gibi	then tell us :)
16:20:00	sp-bmilanov	I wonder if it would be better to bring this up when more core people are around but still -- we hit this bug recently and it was not due to a graceful Nova agent shutdown
16:20:24	gibi	what was the trigger?
16:20:55	sp-bmilanov	the tldr; is that during a migration, if a nova-agent crashes at the correct moment, it is possible to have the same VM running on the source and destination hypervisor
16:21:22	dansmith	I think it has already been noted on that bug that nova-compute doesn't really have any graceful shutdown support, and what the bug describes during a live migration is pretty much expected at the moment
16:22:14	gibi	even with graceful shutdown a crash would not be handled
16:22:29	sp-bmilanov	dansmith: right, I read Sean's comment as "it is not supported to ask nova-compute to shutdown during live migration"
16:22:31	dansmith	gibi: I think the problem is likely on restart we re-activate the instance
16:22:36	gibi	so I guess we need a solution where a compute starting up can fix the situation
16:22:46	gibi	dansmith: yeah

Earlier   Later