Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2026-03-13
14:29:54 sean-k-mooney vai the notifcaiotn socket
14:30:06 sean-k-mooney but im not sure we shoudl add any mroe integration for the graceful shutdown timeout
14:30:21 sean-k-mooney at least not nativly in nova
14:30:41 sean-k-mooney puting it in oslo and having nova use it might be more reasonable
14:31:46 sean-k-mooney zigo: by the way we see the same issue in the 3.14 tox job upstream
14:31:51 sean-k-mooney we just have nto had time to fix it
14:32:10 sean-k-mooney oslo_service.backend.exceptions.BackendAlreadySelected: Backend already set to 'eventlet', cannot reinitialize with 'threading' is why that job is currently failing
14:33:27 sean-k-mooney zigo: one issue is we have not added py314 here yet https://github.com/openstack/nova/blob/master/tox.ini#L59
14:34:16 zigo sean-k-mooney: Exactly my thought, which is why I just wrote: https://review.opendev.org/c/openstack/oslo.service/+/980440
14:34:20 sean-k-mooney so its going to fallback to https://github.com/openstack/nova/blob/master/tox.ini#L55
14:34:31 sean-k-mooney which does not include the exclude list
14:34:45 zigo I haven't used dbus-python, that'd be an external dependency, so I had to use subprocess to get the TimeoutStopUSec.
15:10:45 gmaan zigo: 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 lib
15:12:37 gmaan considering 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 timeout
15:15:10 sean-k-mooney we woudl need ot have the config take precedence anyway
15:15:25 sean-k-mooney we coudl perhaps take a defualt form systemd if not set in the config
15:15:52 sean-k-mooney but we need the config when nova is deployed in a continer or on a system without systemd
15:17:15 gmaan yeah, 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 way
15:17:54 gmaan i think default in systemd is 60 sec which is anyways not enough for nova as we have manager wait time default to 160
15:20:19 opendevreview Balazs Gibizer proposed openstack/nova master: Fix running test with py314 https://review.opendev.org/c/openstack/nova/+/980457
15:20:19 opendevreview Balazs Gibizer proposed openstack/nova master: Move py312-threading to py313 https://review.opendev.org/c/openstack/nova/+/980458
15:20:34 gibi sean-k-mooney: zigo: ^^ fix for the py314 unit test job
15:21:04 sean-k-mooney gibi: cool i just didnt have a time to look into that myself but ill review thoese before i leave today
15:36:27 opendevreview Ashish Gupta proposed openstack/nova master: Run functional test with threading mode https://review.opendev.org/c/openstack/nova/+/979850
15:36:27 opendevreview Ashish Gupta proposed openstack/nova master: Add native threading support to test case ID propagation fixtures https://review.opendev.org/c/openstack/nova/+/980179
15:53:01 dansmith nicolairuckel: around by chance?
15:55:56 nicolairuckel dansmith: I just sat down on my computer
15:55:58 nicolairuckel good timing
15:56:08 nicolairuckel at my computer
15:56:13 nicolairuckel on would be weird I guess
15:56:13 opendevreview Thibaut Démaret proposed openstack/nova master: libvirt: add disk rotation_rate support for local disks https://review.opendev.org/c/openstack/nova/+/979693
15:56:34 dansmith nicolairuckel: 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:57:00 dansmith nicolairuckel: 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 tweak
15:57:00 nicolairuckel the backport for 2025.2?
15:57:08 dansmith nicolairuckel: actually just the thing we already merged
15:57:35 dansmith so 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 instance
15:58:10 dansmith what 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 :P
15:58:37 dansmith anyway, am I missing something about the "template" behavior overwriting the boot config as expected behavior or something?
15:59:02 nicolairuckel that sounds odd to me. In my testing the variable and content were still there.
15:59:43 dansmith all 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...
16:00:13 nicolairuckel did you use efivar to set the variable?
16:00:26 dansmith no, I used efibootmgr
16:00:34 dansmith if you can tell me how to get efivar to work I'd love to hear it :)
16:00:45 nicolairuckel one second
16:01:17 nicolairuckel what I did was the following
16:01:22 nicolairuckel sudo apt update && sudo apt install efivar
16:01:30 nicolairuckel $ echo "Nova UEFI" > foo
16:01:34 nicolairuckel $ sudo efivar -n 56da3878-c379-4f5b-be22-72f6f82b6a52-Nova -w -f ./foo
16:01:41 nicolairuckel $ efivar -n 56da3878-c379-4f5b-be22-72f6f82b6a52-Nova
16:01:43 opendevreview Thibaut Démaret proposed openstack/nova master: libvirt: add disk rotation_rate support for local disks https://review.opendev.org/c/openstack/nova/+/979693
16:02:13 nicolairuckel and then openstack server reboot/start/stop/migrate
16:02:21 dansmith yeah
16:02:33 nicolairuckel and then efivar -l and efivar -n again
16:02:34 dansmith lemme try efivar again..
16:02:47 dansmith that uuid is just one you generated, right not anything magical?
16:02:56 nicolairuckel ah, right
16:03:17 nicolairuckel that was something I got from OpenStack
16:03:21 nicolairuckel the server ID
16:03:27 dansmith but does it matter?
16:03:41 dansmith I was just using uuidgen to snag one and it never seemed to want to let me do it
16:03:45 nicolairuckel That's a good question. I just wrote in my notes that it should be the server ID
16:03:59 nicolairuckel yeah, I remember something like that
16:04:01 dansmith okay lemme try both
16:04:50 dansmith does not have to be server id
16:05:21 dansmith I 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:30 dansmith so let me see if that sticks after the reboot
16:07:16 dansmith sho'nuf.. works as expected
16:07:44 dansmith I dunno, I got myself very turned around with efivar before and thought I'd just manipulate the boot config since that was less obscure anyway
16:07:58 dansmith there must be something going on that overwrites that boot config on startup or something, I dunno why
16:08:13 dansmith but the efivar method to verify is what I originally wanted, so thanks for that :)
16:08:19 nicolairuckel You're welcome
16:08:36 nicolairuckel I just used efivar because my colleague showed me the commands I needed.
16:08:52 nicolairuckel That's why I never tried efibootmgr.
16:10:33 dansmith yeah, well, efivar is very undocumented and obscure so I had trouble getting ti to behave *shrug*
16:11:12 nicolairuckel I think that's why I never bothered to figure out why at some point the UUID had to be the server ID.
16:11:35 nicolairuckel But I added that to my notes that this isn't actually the case.
16:11:37 dansmith but to be clear, it doesn't.. I just used uuigen to get one
16:11:40 dansmith yeah, cool
16:12:00 nicolairuckel I wonder if that was a problem in my first implementation where I copied the variables manually instead of using libvirt.
16:12:19 nicolairuckel And since using the server ID still works, I never realized that it's not necessary anymore.
16:15:41 nicolairuckel thanks for testing it again
16:16:22 dansmith yup, I was doing something similar for vTPM to prove it works
16:16:28 dansmith again requiring obscure and temperamental tooling
16:16:38 dansmith s/works/persists
16:16:40 nicolairuckel Even 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. :D
16:16:45 dansmith heh
18:21:59 gmaan does anyone knows why we are keeping nova/keymgr/conf_key_mgr.py ? https://github.com/openstack/nova/blob/master/nova/keymgr/conf_key_mgr.py
18:22:33 gmaan I 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-L460C34
18:23:47 gmaan melwitt: ^^ 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#L94
18:24:48 gmaan any other place we use this fixed_key backend (nova/keymgr/conf_key_mgr.py) then testing in unit/functional or devstack testing?
18:25:29 gmaan or stephenfin ^^ as you modified it last (though 3 years ago :))
18:42:31 stephenfin gmaan: 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 seen
18:44:04 gmaan stephenfin: ack, thanks. that is enough information for now. but ++ on moving
20:00:29 melwitt Uggla, 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/+/978144
20:01:51 gmaan melwitt: oh, there is another one. I thought vtpm amendment was the only one left
20:02:31 melwitt yeah, I noticed it :/
20:02:50 melwitt alternatively we could move the specs and then make the amendment have to update
20:03:44 gmaan as amenedment one is in gate, maybe let's merge that and Uggla can rebase the spec move one
20:05:55 melwitt I thought it should go first and then second guessed it.
20:06:22 gmaan yeah

Earlier   Later