16:01:59 <Uggla> #startmeeting nova
16:01:59 <opendevmeet> Meeting started Tue Oct 14 16:01:59 2025 UTC and is due to finish in 60 minutes.  The chair is Uggla. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:01:59 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:01:59 <opendevmeet> The meeting name has been set to 'nova'
16:02:36 <gibi> o/
16:02:38 <bauzas> o/
16:02:43 <nicolairuckel> o/
16:02:43 <gmaan> o/
16:02:44 <opendevreview> Takashi Natsume proposed openstack/nova master: Update contributor guide for 2026.1 Gazpacho  https://review.opendev.org/c/openstack/nova/+/961896
16:02:45 * gibi is on a parallel meeting
16:02:46 <fwiesel> o/
16:03:24 <Uggla> hey gmaan welcome back ;)
16:04:17 <gibi> gmaan: oooh hi!
16:04:26 <sean-k-mooney> o/
16:04:27 <gmaan> hi
16:05:04 <Uggla> Let's start slowly.
16:05:10 <elodilles> o/
16:05:27 <Uggla> #topic Bugs (stuck/critical)
16:05:36 <Uggla> #info No Critical bug
16:05:53 <Uggla> #topic Gate status
16:06:05 <Uggla> #link https://bugs.launchpad.net/nova/+bugs?field.tag=gate-failure Nova gate bugs
16:06:11 <Uggla> #link https://etherpad.opendev.org/p/nova-ci-failures-minimal
16:06:20 <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 status
16:06:36 <Uggla> #info Please look at the gate failures and file a bug report with the gate-failure tag.
16:06:42 <Uggla> #info Please try to provide a meaningful comment when you recheck
16:06:56 <Uggla> shame on me I have not looked at the gate.
16:07:19 <Uggla> Have you seen something bad with it ?
16:08:38 <bauzas> I saw some failures but the ones I was knowing
16:08:55 <sean-k-mooney> bauzas: volume issue and kernel panics?
16:09:12 <bauzas> ssh timeout at least
16:09:15 <gibi> I saw guest ssh timeouts in couple of times in different test cases but did not dig deep
16:09:16 <sean-k-mooney> ack
16:09:30 <bauzas> eg. https://zuul.opendev.org/t/openstack/build/83dac09bed7947dead180357cb14d357
16:09:31 <gibi> ohh we have matching observation
16:09:53 <sean-k-mooney> that ocationaly happens but if its increaseing we may need to debug
16:10:09 <bauzas> we'll see with my rechecks :)
16:10:42 <sean-k-mooney> gibi: was the issue with some vms geting multipel port fixed do you know?
16:11:00 <sean-k-mooney> im not saying that related but just wondering if you new
16:11:01 <gibi> I don't recall the issue
16:11:03 <sean-k-mooney> *knew
16:11:09 <sean-k-mooney> ack no worries
16:11:26 <gibi> anyhow or the guest ssh I will keep an eye on it
16:11:34 <sean-k-mooney> one of the provider was allcoating mulitple port to nodpoolvms which sometimes broke the network connectivy on the computes
16:11:41 <sean-k-mooney> i assume that has been fixed
16:11:53 <sean-k-mooney> it wasnt a nova problem
16:11:53 <gibi> ohh now I recall it. I haven't see that appearing recently
16:11:58 <sean-k-mooney> ack
16:12:23 <sean-k-mooney> that job only has one port as expected so as i said not related
16:13:50 <sean-k-mooney> we can proably move on unless anyone else has somethign
16:14:10 <gibi> jepp, lets move on
16:14:17 <Uggla> I agree
16:14:25 <Uggla> Skipping next point, as I want gmaan to come back smoothly.
16:14:35 <Uggla> #topic Release Planning
16:14:46 <Uggla> #link https://releases.openstack.org/gazpacho/schedule.html
16:14:57 <Uggla> #info PTG etherpad for 2026.1 is available: https://etherpad.opendev.org/p/nova-2026.1-ptg
16:15:11 <Uggla> #info Please add the topics you would like to discuss in the above document.
16:15:21 <Uggla> #info PTG meetings (to be confirmed) will happen room grizzly 15:00UTC -> 17:00UTC from Tuesday to Friday
16:16:03 <Uggla> Note, I'm currently crafting the PTG etherpad defining the timeslots.
16:16:11 <gibi> Uggla: 15-16, 16-17, or also 17-18?
16:16:36 <gibi> I mean the last starting time is 17UTC or the finish time is 17 UTC?
16:16:39 <sean-k-mooney> yep ^ its an inclusive range of startimes
16:16:52 <sean-k-mooney> so its really 15:00-18:00
16:17:05 <Uggla> yep 15:00 --> 18:00 CET
16:17:05 <gibi> ack, so 3 hours for 4 days
16:17:11 <gibi> works forme
16:17:15 <sean-k-mooney> based on https://ptg.opendev.org/ptg.html
16:17:34 <Uggla> yep as usual, starting (Tue)
16:17:52 <sean-k-mooney> well you need to adjust that actully
16:18:03 <sean-k-mooney> it curernly show all 5 hours not just the fine 3 in the slot
16:20:01 <Uggla> sean-k-mooney yes I reserved a bit larger at the first shot
16:21:29 <bauzas> at least the slots are booked
16:21:39 <Uggla> yep :)
16:21:53 <bauzas> if we need to continue to discuss, we can book another slot... or we can unbook another one :)
16:22:28 <Uggla> I'will arrange that in the coming days
16:24:57 <Uggla> ok moving on
16:25:03 <Uggla> #topic OpenAPI
16:25:13 <Uggla> #link: https://review.opendev.org/q/topic:%22openapi%22+(project:openstack/nova+OR+project:openstack/placement)+-status:merged+-status:abandoned
16:25:20 <Uggla> #info still 28 remaining atm.
16:25:43 <Uggla> #topic Stable Branches
16:25:55 * Uggla giving the voice to elodilles
16:26:12 <elodilles> thanks o/
16:26:20 <elodilles> #info stable branches (stable/2025.* and stable/2024.*) seem to be in OK state
16:26:26 <elodilles> #info stable branch status / gate failures tracking etherpad: https://etherpad.opendev.org/p/nova-stable-branch-ci
16:26:40 <elodilles> #info 2024.1 Caracal (stable/2024.1) moves to Unmaintained at the end of next week - final stable Caracal release should be proposed and merged ASAP
16:26:56 <elodilles> #info elod will propose the release patches tomorrow
16:27:06 <elodilles> and a question:
16:27:13 <elodilles> does anyone have any important patch to land to stable/2024.1 before we release? (list of open patches: https://etherpad.opendev.org/p/nova-stable-caracal-eom )
16:27:30 <Uggla> -
16:27:36 <gibi> -
16:27:40 <elodilles> thanks for the reviews so far, btw!
16:28:37 <elodilles> Uggla: gibi: ACK, then i'll propose the review patches right away (flamingo, epoxy, dalmatian, caracal)
16:28:51 <elodilles> (though caracal is the most important for now o:))
16:29:07 <elodilles> and that's all from me about stable for now
16:29:10 <gibi> poor caracal, I will miss it
16:29:15 <elodilles> :]
16:29:15 <Uggla> rip caracal
16:29:37 <elodilles> you don't have to dig it, it won't go to EOL, just Unmaintained o:)
16:29:55 <elodilles> so people can still backport bug fixes to unmaintained/2024.1 ;)
16:30:01 <sean-k-mooney> elodilles: as an aside there is only ment to be one unmtianed slurp release at a time
16:30:14 <gibi> yeah basicaly kicked out to the streets nice elodilles :)
16:30:23 <sean-k-mooney> elodilles: im fine with not enforce that as long as you still care about the rest
16:30:49 <elodilles> sean-k-mooney: in case there is no volunteer to keep open unmaintained/2023.1
16:30:49 <sean-k-mooney> but in thory 2023.1 is ment to go eol when 2024.1 moves to unmainted
16:31:09 <gmaan> antelope is still unmaintained, any plan to move to EOL before caracal moving to unmaintained ?
16:31:18 <gmaan> sean-k-mooney: yeah
16:31:38 <sean-k-mooney> so i think elodilles  is still interested in keeping it alive
16:31:44 <gmaan> because based on that we need to see if we can continue running grenade job on unmaintained caracal
16:31:46 <sean-k-mooney> so as long as the gates are green that is fine
16:32:10 <sean-k-mooney> well grenade is not ment to test upgrades form unmaintained
16:32:46 <gmaan> as long as it run green then no harm to test it but if previous base relaese is not maintained or broken then yes we can remove
16:32:48 <elodilles> sean-k-mooney: yes, i want to step up as a volunteer to keep it open
16:33:04 <sean-k-mooney> or rahter the oldest stable is not ment to test upgrading form unmaintaiend but you coudl run it your self i guess
16:34:53 <elodilles> sean-k-mooney: yes, the oldest stable is officially not supported, so can be disabled, though if it works then i'd rather ask for keeping it, and also help maintaining it as long as it possible
16:35:24 <sean-k-mooney> well the counter point to that
16:35:38 <sean-k-mooney> is we want to evntually be able to remove old disto images and mirrors
16:36:11 <sean-k-mooney> so im not objecting to keepign it for a release or two bvut we shoudl nto keep it indefinetly
16:36:18 <elodilles> of course if it blocks the gate then it can be removed (though i'd rather set it as non-voting if not completely unfixable or broken forever)
16:36:49 <elodilles> sean-k-mooney: +1
16:36:50 <sean-k-mooney> 2023.1 is using ubuntu 22.04 which is supprot until 2027
16:36:58 <sean-k-mooney> that kind of the upper bound on testing that IMO
16:37:29 <sean-k-mooney> so it has 18months+ runway i think
16:37:53 <sean-k-mooney> anyway we can likely move on since its not being EOLd this cycle but we could talk about it more at the ptg if poepel wanted
16:38:40 <elodilles> yepp
16:39:04 <gmaan> I am only concern about the running grenade skip job on Epoxy which will be from caracal to Epoxy and if we can continue running it it will be great
16:39:25 <gmaan> and it seems like we will do that until it is broken so I am good here
16:39:41 <elodilles> gmaan: ++
16:40:28 <Uggla> ok so moving on.
16:40:36 <Uggla> thx elodilles
16:40:42 <Uggla> #topic vmwareapi 3rd-party CI efforts Highlights
16:40:50 <fwiesel> No updates from my side
16:41:03 <Uggla> fwiesel thanks
16:41:15 <Uggla> #topic Gibi's news about eventlet removal
16:41:18 <gibi> o/
16:41:37 <Uggla> gibi anything on your side ?
16:42:06 <gibi> then first couple of patches are reviewable on https://review.opendev.org/c/openstack/nova/+/956089/
16:42:16 <gibi> and the ptg etherpad as the longer term plan
16:42:53 <gibi> Also please report any strange test failures from nova-next, since last week we run conduct there in threading mode as well
16:43:08 <gibi> (top of scheduler api, and metadata)
16:43:13 <gibi> that is ti
16:43:15 <gibi> it
16:43:18 <sean-k-mooney> hum on the rbd thread pool i guess everually we will wnat to use the asinc api instead
16:43:30 <sean-k-mooney> so we can actully pass timeouts ectra
16:44:17 <sean-k-mooney> but i guess the intial plan is to just not swapn it on a tread pool at  all which i guess is ok
16:44:19 <gibi> sean-k-mooney: this will not prevent doing that later when we actaully go and translate the nova-compute
16:44:44 <sean-k-mooney> ack ya just chekcign that still the medium term plan
16:44:46 <gibi> the patches on that series are for unblocking unit testing
16:44:47 <opendevreview> Merged openstack/nova master: Move cleanup of vTPM secret from driver to compute  https://review.opendev.org/c/openstack/nova/+/962007
16:45:17 <sean-k-mooney> ah ok
16:47:03 <gibi> I think we can move on
16:47:11 <Uggla> thx gibi
16:47:20 <Uggla> #topic Open discussion
16:47:45 <Uggla> Just a reminder for the poll:  Pool for the new schedule of upstream meeting: https://framadate.org/ao12zK6wR3K3nfbF
16:48:10 <Uggla> Anything you want to discuss ?
16:48:25 <nicolairuckel> I worked on a patch to preserve the NVRAM after reboots that got mentioned a few weeks ago.
16:48:39 <nicolairuckel> I'm not sure if that's the correct place to talk about that.
16:48:47 <Uggla> yes
16:48:54 <nicolairuckel> https://review.opendev.org/c/openstack/nova/+/959682
16:49:28 <sean-k-mooney> looks like it needs a rebase
16:49:59 <nicolairuckel> The only caveat is that at the moment you have to set the permissions for the NVRAM file manually. I wasn't able to figure out if there's a way to change the permissions through libvirt.
16:50:08 <nicolairuckel> sean-k-mooney, I'll do that!
16:50:35 <sean-k-mooney> why do you need to do that?
16:51:27 <nicolairuckel> If you don't add read permissions, there will be a permissions error on a reboot and it won't be preserved.
16:52:04 <nicolairuckel> The libvirt people told me that the permissions are like than intentionally. It's just a bit weird to me that the disk file has read permissions.
16:52:04 <sean-k-mooney> wait why are you copying the file to the instnce dir an back
16:52:23 <sean-k-mooney> https://review.opendev.org/c/openstack/nova/+/959682/3/nova/virt/libvirt/driver.py#10919
16:52:32 <nicolairuckel> The file contains the UEFI variables that I want to preserve.
16:52:42 <sean-k-mooney> i tought we were goign to preseve this by passign the libvirt flag to the doamin cleanup to preserve the file
16:53:36 <nicolairuckel> You mean I could skip copying the file?
16:53:42 <sean-k-mooney> yes
16:53:58 <nicolairuckel> I see. I'm going to try that.
16:53:59 <sean-k-mooney> so for the vtpm data we can pass a flag to tell libvirt not to delete it when the domein is undefiend
16:54:05 <sean-k-mooney> i belive we can do the same for the nvram
16:54:19 <sean-k-mooney> i could be mistaken but i belive there was a flag for the nvram as well
16:54:24 <nicolairuckel> That would be a better solution for sure.
16:54:26 <sean-k-mooney> so we would not need ot copy the file
16:54:37 <nicolairuckel> I'm going to look into that, thank you.
16:55:12 <nicolairuckel> How can I find a reviewer when that is done? Should I just bring it up again next week?
16:56:47 <sean-k-mooney> you can also ping on irc
16:56:52 <nicolairuckel> okay
16:57:01 <sean-k-mooney> we will proably see it updated but you can reach out if we dont
16:57:03 <Uggla> nicolairuckel, ping on the channel
16:57:16 <nicolairuckel> thanks
16:57:23 <nicolairuckel> that would be all from my side then
16:57:56 <gibi> nicolairuckel: thanks for working on it
16:58:24 <sean-k-mooney> VIR_DOMAIN_UNDEFINE_KEEP_NVRAM
16:58:39 <sean-k-mooney> https://github.com/libvirt/libvirt/blob/b42a12174c787b99cd6fcb29b44e4b13bd64ee58/include/libvirt/libvirt-domain.h#L2373
16:58:52 <sean-k-mooney> that the flag we need to pass to not delete it when the domain is undeifed
16:58:57 <Uggla> nicolairuckel, yes thanks for working on it
17:00:14 <Uggla> time to close
17:00:32 <Uggla> Thank you for participating in this meeting.
17:00:39 <Uggla> #endmeeting