Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2026-03-13
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 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:13 nicolairuckel on would be weird I guess
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 nicolairuckel the backport for 2025.2?
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: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
20:07:31 melwitt I 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 too
20:11:03 gmaan ++
20:13:26 opendevreview Merged openstack/nova-specs master: Update remove-os-volumes_boot-api to reflect changes https://review.opendev.org/c/openstack/nova-specs/+/978144
22:05:19 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
22:32:15 opendevreview Stephen Finucane proposed openstack/nova stable/2025.2: api: Handle empty imageRef alongside null for local BDM check https://review.opendev.org/c/openstack/nova/+/980540
22:32:40 opendevreview Stephen Finucane proposed openstack/nova stable/2025.1: api: Handle empty imageRef alongside null for local BDM check https://review.opendev.org/c/openstack/nova/+/980541
22:32:59 opendevreview Stephen Finucane proposed openstack/nova stable/2025.1: api: Handle empty imageRef alongside null for local BDM check https://review.opendev.org/c/openstack/nova/+/980541
#openstack-nova - 2026-03-14
02:31:03 opendevreview melanie witt proposed openstack/nova master: Add nova-vtpm job https://review.opendev.org/c/openstack/nova/+/978841
04:36:22 opendevreview OpenStack Proposal Bot proposed openstack/nova master: Imported Translations from Zanata https://review.opendev.org/c/openstack/nova/+/980544
#openstack-nova - 2026-03-15
23:14:36 opendevreview sean mooney proposed openstack/nova master: [WIP] perf: add ironic startup perf simulator and analysis https://review.opendev.org/c/openstack/nova/+/980641
23:30:34 opendevreview sean mooney proposed openstack/nova master: [WIP] perf: add ironic startup perf simulator and analysis https://review.opendev.org/c/openstack/nova/+/980641
#openstack-nova - 2026-03-16
07:57:26 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
09:03:05 rmnijgh Hi! It came to my attention that nova live migrate also calls the periodic task update_available_resource() in the post_live_migration...
09:03:44 rmnijgh However, this tasks can take a few minutes. And in those minutes the migration task is still seen as running, even though the migration is already finished.
09:04:21 rmnijgh Is this necessary to run at post_live_migrate? Since this task already runs periodically (I believe every 2 minutes by default)
09:05:16 rmnijgh Not having this function at post_live_migrate completes migration tasks significantly faster
09:49:06 rmnijgh I've just found a bug report with the exact problem I am experiecing #2085709 :D
10:10:31 opendevreview ribaudr proposed openstack/nova-specs master: Move Gazpacho implemented specs https://review.opendev.org/c/openstack/nova-specs/+/979283
10:37:10 opendevreview sean mooney proposed openstack/nova master: [WIP] perf(ironic): eliminate O(N²) ProviderTree deepcopy at startup (B6) https://review.opendev.org/c/openstack/nova/+/980676
10:37:10 opendevreview sean mooney proposed openstack/nova master: [WIP] perf: add ironic startup perf simulator and analysis https://review.opendev.org/c/openstack/nova/+/980641
10:37:11 opendevreview sean mooney proposed openstack/nova master: [WIP] perf(ironic): background _error_out_interrupted during startup (B4) https://review.opendev.org/c/openstack/nova/+/980678
10:37:11 opendevreview sean mooney proposed openstack/nova master: [WIP] perf(ironic): suppress redundant _refresh_cache calls during startup (B1) https://review.opendev.org/c/openstack/nova/+/980677
10:37:12 opendevreview sean mooney proposed openstack/nova master: [WIP] docs: update startup.md with post-optimisation measurements https://review.opendev.org/c/openstack/nova/+/980680
10:37:12 opendevreview sean mooney proposed openstack/nova master: [WIP] perf(compute): parallelise per-node update_available_resource loop (B2) https://review.opendev.org/c/openstack/nova/+/980679
10:50:15 sean-k-mooney rmnijgh: it calls it because it was oen of the ways we heal the resouces asyncornsly, it runs every 5 mintues by defualt. it used to be used to move pci device form claimed to allocated. although on newer release i belive we do that seperatly
10:51:51 sean-k-mooney i dont think that call shoudl be needed in antelop+ possibly a little eailer but

Earlier   Later