Friday, 2026-03-13

opendevreviewAshish Gupta proposed openstack/nova master: Add native threading support to test case ID propagation fixtures  https://review.opendev.org/c/openstack/nova/+/98017906:31
opendevreviewLajos Katona proposed openstack/nova master: Use SDK for Neutron Ports  https://review.opendev.org/c/openstack/nova/+/96929809:04
* gibi just read back on the metadata server allowing POSTing password and grossed out 09:50
opendevreviewLajos Katona proposed openstack/nova master: Use SDK for Neutron Ports  https://review.opendev.org/c/openstack/nova/+/96929809:56
opendevreviewOpenStack Release Bot proposed openstack/nova stable/2026.1: Update .gitreview for stable/2026.1  https://review.opendev.org/c/openstack/nova/+/98040410:14
opendevreviewOpenStack Release Bot proposed openstack/nova stable/2026.1: Update TOX_CONSTRAINTS_FILE for stable/2026.1  https://review.opendev.org/c/openstack/nova/+/98040510:14
opendevreviewOpenStack Release Bot proposed openstack/nova master: Update master for stable/2026.1  https://review.opendev.org/c/openstack/nova/+/98040610:14
opendevreviewribaudr proposed openstack/nova-specs master: Move Gazpacho implemented specs  https://review.opendev.org/c/openstack/nova-specs/+/97928310:51
zigoHi there!10:58
zigoFrom Gazpacho Nova's release notes, I can read:10:58
zigoThe default value of [DEFAULT]/graceful_shutdown_timeout has been changed from 60 to 180 seconds for all Nova services. This means that when a Nova service receives SIGTERM, it will now wait up to 180 seconds for a graceful shutdown before being forcefully terminated.10:58
zigoWhat service is impacted for this? I10:58
zigoI'm guessing: nova-compute and nova-conductor, right?10:58
zigoBut scheduler as well?10:58
zigoTo me, it looks like, yes (reading the code).10:59
zigoI think it'd be nicer for Nova to read what's in systemd, using the d-bus interface. Would this kind of patch be accepted (if made optional, since not everyone uses systemd) ?11:02
gibigmaan: ^^ 11:16
zigoAlso, when attempting to run Nova unit tests, I get failure during test discovery:11:16
zigooslo_service.backend.exceptions.BackendAlreadySelected: Backend already set to 'eventlet', cannot reinitialize with 'threading'11:16
zigoAm I missing something?11:16
gibizigo: I think we agree that synchorizing the timeouts between systemd / k8s liveness probe / etc with the nova's shutdown timout is needed. But it is hard to automate it as it depends on how nova is deployed. It is not always systemd11:17
gibizigo: which python version are you using for the unit test?11:17
gibizigo: I think the graceful shutdown timeout change effects all nova sevices except the APIs. But gmaan can confirm11:18
gibizigo: we see similar unit test issue in py3.14 https://zuul.opendev.org/t/openstack/build/156fe0f67bff4e4da43a31bd0f02e66711:20
gibiI had not time to dig. But py3.13 is pretty stable11:20
gibi(3.14 is still not voting for us so it is easy to ignore'l11:21
gibi)11:21
zigogibi: 3.13 and 3.14.11:26
zigoFlamingo on 3.14 was no issue.11:27
zigo(sorry, in a meeting, wont take too long)11:27
gibiack. If you see the issue in 3.13 that is strange. But anyho please file a bug I will try to get to it11:28
zigoWhat I'm seeing: https://paste.opendev.org/show/bB5CJ9SHLPXOjKGyu0N8/11:36
zigoI'm seeing the issue in 3.14 only, because it's not running 3.13 tests if 3.14 fails.11:36
zigogibi: Well, I can dig it out, just, do I have a workaround? Maybe export a variable so it uses only threading?11:38
zigoFound it: OS_NOVA_DISABLE_EVENTLET_PATCHING11:40
zigoOk, tests are running now... Hopefully, no breakage because of this! :)11:42
zigogibi: How safe is it to use OS_NOVA_DISABLE_EVENTLET_PATCHING in all services?11:49
zigoLooks like one unit test is stuck... :(11:49
opendevreviewAshish Gupta proposed openstack/nova master: Run functional test with threading mode  https://review.opendev.org/c/openstack/nova/+/97985012:04
opendevreviewAshish Gupta proposed openstack/nova master: Add native threading support to test case ID propagation fixtures  https://review.opendev.org/c/openstack/nova/+/98017912:04
nicolairuckelCould anyone take a look at this? https://zuul.opendev.org/t/openstack/build/59d2bc927a5d4e40936da1ccc05722e6 The job run successfully before with exactly the same code.12:08
zigogibi: Unit tests are passing, if I set OS_NOVA_DISABLE_EVENTLET_PATCHING=false in d/rules.12:16
gibizig12:49
gibizigo: so using native threading via OS_NOVA_DISABLE_EVENTLET_PATCHING=true is experimental. If you can test it the we are eager to hear feedback. All services except the console proxies can be run with native threading12:50
zigoWell, for tests to run, I had to set it to false ! :/12:50
gibihttps://docs.openstack.org/nova/latest/admin/concurrency.html12:50
gibithis is the main doc12:50
zigoI'll try whenever I'm at the tempest phase.12:50
gibifor unit testing we have an exclude list https://github.com/openstack/nova/blob/d5c64e7aba09052601b59bf1297187d85da6b90b/tox.ini#L8312:51
gibifunctional tests does not yet work with native threading12:51
gibitempest passes in nova-next job where we configure each service with native threading12:52
zigoOh... Thanks, that's really helpful.12:52
sean-k-mooneyzigo: we have optional systemd/debus integration14:29
sean-k-mooneyfor sending ready14:29
sean-k-mooneyvai the notifcaiotn socket14:29
sean-k-mooneybut im not sure we shoudl add any mroe integration for the graceful shutdown timeout14:30
sean-k-mooneyat least not nativly in nova14:30
sean-k-mooneyputing it in oslo and having nova use it might be more reasonable14:30
sean-k-mooneyzigo: by the way we see the same issue in the 3.14 tox job upstream14:31
sean-k-mooneywe just have nto had time to fix it14:31
sean-k-mooneyoslo_service.backend.exceptions.BackendAlreadySelected: Backend already set to 'eventlet', cannot reinitialize with 'threading' is why that job is currently failing14:32
sean-k-mooneyzigo: one issue is we have not added py314 here yet https://github.com/openstack/nova/blob/master/tox.ini#L5914:33
zigosean-k-mooney: Exactly my thought, which is why I just wrote: https://review.opendev.org/c/openstack/oslo.service/+/98044014:34
sean-k-mooneyso its going to fallback to https://github.com/openstack/nova/blob/master/tox.ini#L5514:34
sean-k-mooneywhich does not include the exclude list14:34
zigoI haven't used dbus-python, that'd be an external dependency, so I had to use subprocess to get the TimeoutStopUSec.14:34
gmaanzigo: RE on graceful shutdown: yes that timeout is in effect for the services using oslo.services which are 1. compute 2. sch 3. conductor. The other remaining services api, metadata api, console proxy shutdown path is different and it depends/handled by their underlying wsgi server/websokify lib15:10
gmaanconsidering the different external system to deploy the services, its not good idea to automate the timeout as per the single deployment model like systemd. We recommend to override this timeout in conf as per the external system timeout15:12
sean-k-mooneywe woudl need ot have the config take precedence anyway15:15
sean-k-mooneywe coudl perhaps take a defualt form systemd if not set in the config15:15
sean-k-mooneybut we need the config when nova is deployed in a continer or on a system without systemd15:15
gmaanyeah, I am not sure how much value it will add to just automate for systemd instead operator checking and setting it in config if current default is not good is better and explicit way15:17
gmaani think default in systemd is 60 sec which is anyways not enough for nova as we have manager wait time default to 16015:17
opendevreviewBalazs Gibizer proposed openstack/nova master: Fix running test with py314  https://review.opendev.org/c/openstack/nova/+/98045715:20
opendevreviewBalazs Gibizer proposed openstack/nova master: Move py312-threading to py313  https://review.opendev.org/c/openstack/nova/+/98045815:20
gibisean-k-mooney: zigo: ^^ fix for the py314 unit test job15:20
sean-k-mooneygibi: cool i just didnt have a time to look into that myself but ill review thoese before i leave today15:21
opendevreviewAshish Gupta proposed openstack/nova master: Run functional test with threading mode  https://review.opendev.org/c/openstack/nova/+/97985015:36
opendevreviewAshish Gupta proposed openstack/nova master: Add native threading support to test case ID propagation fixtures  https://review.opendev.org/c/openstack/nova/+/98017915:36
dansmithnicolairuckel: around by chance?15:53
nicolairuckeldansmith: I just sat down on my computer15:55
nicolairuckelgood timing15:55
nicolairuckelat my computer15:56
nicolairuckelon would be weird I guess15:56
opendevreviewThibaut Démaret proposed openstack/nova master: libvirt: add disk rotation_rate support for local disks  https://review.opendev.org/c/openstack/nova/+/97969315:56
dansmithnicolairuckel: hey, so I was trying to verify your nvram fix (which maybe I should have done before) but.. I think I must be missing something...15:56
dansmithnicolairuckel: to make sure it works, I was going to just tweak the efibootmgr config a bit and then power cycle the instance to make sure it kept the tweak15:57
nicolairuckelthe backport for 2025.2?15:57
dansmithnicolairuckel: actually just the thing we already merged15:57
dansmithso if I create a new fake boot entry and then reboot, it's gone when it comes back, but I see my label string in the VARS.fd for the instance15:57
dansmithwhat I really wanted to do was just use efivar to poke something in there to look for, but was never able to get that undocumented monstrosity to do anything :P15:58
dansmithanyway, am I missing something about the "template" behavior overwriting the boot config as expected behavior or something?15:58
nicolairuckelthat sounds odd to me. In my testing the variable and content were still there.15:59
dansmithall I did was set the firmware type to uefi on the image.. does the platform need to be q35 or something maybe? I wasn't expecting that to matter but...15:59
nicolairuckeldid you use efivar to set the variable?16:00
dansmithno, I used efibootmgr16:00
dansmithif you can tell me how to get efivar to work I'd love to hear it :)16:00
nicolairuckelone second16:00
nicolairuckelwhat I did was the following16:01
nicolairuckelsudo apt update && sudo apt install efivar16:01
nicolairuckel$ echo "Nova UEFI" > foo16:01
nicolairuckel$ sudo efivar -n 56da3878-c379-4f5b-be22-72f6f82b6a52-Nova -w -f ./foo16:01
nicolairuckel$ efivar -n 56da3878-c379-4f5b-be22-72f6f82b6a52-Nova16:01
opendevreviewThibaut Démaret proposed openstack/nova master: libvirt: add disk rotation_rate support for local disks  https://review.opendev.org/c/openstack/nova/+/97969316:01
nicolairuckeland then openstack server reboot/start/stop/migrate16:02
dansmithyeah16:02
nicolairuckeland then efivar -l and efivar -n again16:02
dansmithlemme try efivar again..16:02
dansmiththat uuid is just one you generated, right not anything magical?16:02
nicolairuckelah, right16:02
nicolairuckelthat was something I got from OpenStack16:03
nicolairuckelthe server ID16:03
dansmithbut does it matter?16:03
dansmithI was just using uuidgen to snag one and it never seemed to want to let me do it16:03
nicolairuckelThat's a good question. I just wrote in my notes that it should be the server ID16:03
nicolairuckelyeah, I remember something like that16:03
dansmithokay lemme try both16:04
dansmithdoes not have to be server id16:04
dansmithI dunno why but that just worked.. I spent a stupid amount of time trying to get that to work (granted on a libvirt non-nova VM, maybe there was some config difference)16:05
dansmithso let me see if that sticks after the reboot16:05
dansmithsho'nuf.. works as expected16:07
dansmithI dunno, I got myself very turned around with efivar before and thought I'd just manipulate the boot config since that was less obscure anyway16:07
dansmiththere must be something going on that overwrites that boot config on startup or something, I dunno why16:07
dansmithbut the efivar method to verify is what I originally wanted, so thanks for that :)16:08
nicolairuckelYou're welcome16:08
nicolairuckelI just used efivar because my colleague showed me the commands I needed.16:08
nicolairuckelThat's why I never tried efibootmgr.16:08
dansmithyeah, well, efivar is very undocumented and obscure so I had trouble getting ti to behave *shrug*16:10
nicolairuckelI think that's why I never bothered to figure out why at some point the UUID had to be the server ID.16:11
nicolairuckelBut I added that to my notes that this isn't actually the case.16:11
dansmithbut to be clear, it doesn't.. I just used uuigen to get one16:11
dansmithyeah, cool16:11
nicolairuckelI wonder if that was a problem in my first implementation where I copied the variables manually instead of using libvirt.16:12
nicolairuckelAnd since using the server ID still works, I never realized that it's not necessary anymore.16:12
nicolairuckelthanks for testing it again16:15
dansmithyup, I was doing something similar for vTPM to prove it works16:16
dansmithagain requiring obscure and temperamental tooling16:16
dansmiths/works/persists16:16
nicolairuckelEven though you scared me a bit. For a few minutes I thought I'd have to go back to work on that after telling everyone it was done and merged. :D16:16
dansmithheh16:16
gmaandoes anyone knows why we are keeping nova/keymgr/conf_key_mgr.py ? https://github.com/openstack/nova/blob/master/nova/keymgr/conf_key_mgr.py18:21
*** erlon2 is now known as erlon18:22
gmaanI think it is only for testing and because barbican ins not installed by default in devstack, devstack also use this as key_manager backendhttps://github.com/openstack/devstack/blob/master/lib/nova#L460C23-L460C3418:22
gmaanmelwitt: ^^ maybe you know, as enabling the barbican in vTPM jobs modify the key_manager backend to barbican which actually test the secrets store/get etc https://github.com/openstack/barbican/blob/master/devstack/lib/barbican#L9418:23
gmaanany other place we use this fixed_key backend (nova/keymgr/conf_key_mgr.py) then testing in unit/functional or devstack testing? 18:24
gmaanor stephenfin ^^ as you modified it last (though 3 years ago :)) 18:25
stephenfingmaan: yeah, it's purely for testing. I think I had plans to move it to castellan (e.g. castellan.test) but there were a few references in other projects, as you've seen18:42
gmaanstephenfin: ack, thanks. that is enough information for now. but ++ on moving18:44
melwittUggla, gmaan: I noticed a pending spec amendment patch and thought it should merge first before the "spec move" patch. it will cause a merge conflict in the "spec move" patch, sorry about that https://review.opendev.org/c/openstack/nova-specs/+/97814420:00
gmaanmelwitt: oh, there is another one. I thought vtpm amendment was the only one left20:01
melwittyeah, I noticed it :/20:02
melwittalternatively we could move the specs and then make the amendment have to update20:02
gmaanas amenedment one is in gate, maybe let's merge that and Uggla can rebase the spec move one20:03
melwittI thought it should go first and then second guessed it.20:05
gmaanyeah20:06
melwittI did not expect it to merge conflict bc the spec move is just renaming files. but I guess the file content at the time matters too20:07
gmaan++20:11
opendevreviewMerged openstack/nova-specs master: Update remove-os-volumes_boot-api to reflect changes  https://review.opendev.org/c/openstack/nova-specs/+/97814420:13
opendevreviewAshish Gupta proposed openstack/nova master: Add native threading support to test case ID propagation fixtures  https://review.opendev.org/c/openstack/nova/+/98017922:05
opendevreviewStephen Finucane proposed openstack/nova stable/2025.2: api: Handle empty imageRef alongside null for local BDM check  https://review.opendev.org/c/openstack/nova/+/98054022:32
opendevreviewStephen Finucane proposed openstack/nova stable/2025.1: api: Handle empty imageRef alongside null for local BDM check  https://review.opendev.org/c/openstack/nova/+/98054122:32
opendevreviewStephen Finucane proposed openstack/nova stable/2025.1: api: Handle empty imageRef alongside null for local BDM check  https://review.opendev.org/c/openstack/nova/+/98054122:32

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