| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2026-01-19 | |||
| 17:17:12 | sean-k-mooney | that why we need to stash the state somewhere in the cold migrate and shelve/unshelve case | |
| 17:17:40 | sean-k-mooney | shelve/unshelve today loses the nvram so it will regenerate it regardless today | |
| 17:18:03 | tkajinam | another scenario I still have to consider in additiona to os_firmware_secure='optional' is the case where a different firmware is selected after hard reboot but I'll give more thoughts to it. | |
| 17:18:07 | sean-k-mooney | but again preserving it is out of scope fo the iniall reboot bug | |
| 17:18:21 | tkajinam | an annoying thing is that it's not clear how these firmware files are updated (due to no documentation about their update policy) | |
| 17:19:08 | sean-k-mooney | right the frimware itself and the base tempelates are part of the ovmf package i bleive | |
| 17:19:15 | tkajinam | yeah | |
| 17:19:16 | sean-k-mooney | so they update when the host package is updated | |
| 17:20:05 | sean-k-mooney | tkajinam: when we use the statelest firmware feature do we still have an nvram file? i think no correct? | |
| 17:20:15 | tkajinam | sean-k-mooney, no | |
| 17:20:52 | tkajinam | yeah so one example question which I can't answer now is "can existing code file and var file be updated when ovmf package is updated ? then do we need to reset nvram in that case ?" | |
| 17:21:05 | sean-k-mooney | its unfortunet that windows stores it bitlocker keys or key config in the nvram file | |
| 17:21:30 | tkajinam | I totally agree | |
| 17:21:33 | sean-k-mooney | the update of the ovmf package just updates teh template | |
| 17:21:56 | sean-k-mooney | but i guess nova woudl have update the backign file because the existng nvram was lost on hard-reboot | |
| 17:22:40 | sean-k-mooney | so in parctis it woudl have updated after the next vm reboot after the host package but i dont think that is what shoudl have been expected | |
| 17:23:47 | tkajinam | I hope so but compatibility between template and var is quite unclear, tbvh | |
| 17:24:17 | sean-k-mooney | ya im not really sure how the qemu/libvirt/ovmf comuity expect that too work | |
| 17:24:51 | sean-k-mooney | if they provided a migraton tool to migrate the nvram file to a newer version invoking that woudl be a potinally reasonabel thing to do on hard reboot | |
| 17:25:05 | sean-k-mooney | but im not aware of any such tool | |
| 17:25:16 | sean-k-mooney | it might exsit i have never looked into it | |
| 17:28:46 | sean-k-mooney | ai says no that tool does not exsit for what that worth | |
| 17:29:42 | nicolairuckel | Is there other software that uses qemu, libvirt, or ovmf that may have the same problem? | |
| 17:30:16 | nicolairuckel | Then it might make sense to see how other projects handle that issue. | |
| 17:30:31 | sean-k-mooney | yes, kubvirt, proxmox and virtuozo but apprently the fix is delete the file losing the data and just recreate it in the rare case it does nto work | |
| 17:30:44 | sean-k-mooney | apprently imcompatiablity is rare | |
| 17:30:55 | nicolairuckel | That doesn't sound like a very elegant solution though. | |
| 17:31:20 | sean-k-mooney | its not but unintally that has been what nova did by defualt becuase we were alwsy regenerating it | |
| 17:35:42 | nicolairuckel | I see... | |
| 17:36:57 | sean-k-mooney | nova uefi supprot predates secure boot support and bitlocker using the nvram var to sotre its config so that behavior as not initally observed or problematic | |
| 17:38:00 | sean-k-mooney | i.e. we were not aware that libvirt was deletign the nvram when we underfiend the domain. | |
| 17:42:07 | tkajinam | quick search shows kubevirt supports persistence of uefi vars (which by default does not persist uefi vars) but no useful information about its lifecycle management really :-( | |
| 17:42:16 | tkajinam | https://kubevirt.io/user-guide/compute/persistent_tpm_and_uefi_state/ | |
| 17:44:24 | tkajinam | if anyone from the core have a moment to review/merge https://review.opendev.org/c/openstack/python-novaclient/+/973846 to fix py313 job, that'd be nice. | |
| 17:55:20 | sean-k-mooney | tkajinam: i belive that a releivitly new fetature and it currently has some limeiations | |
| 17:56:02 | sean-k-mooney | tkajinam: there are some internal difcusion with the virt folks about the correct way that and vtpm should sork i bleive and htey havnt really figuried it all out yet | |
| 17:56:31 | tkajinam | hmm | |
| 17:56:36 | sean-k-mooney | i dont really know the details jsu tnoteice it was on the virt devel list which might be upstream actully not sure | |
| 17:57:16 | sean-k-mooney | there was some discussion about live migration and the use of pvcs to store the nvram/tpm data | |
| 17:57:54 | sean-k-mooney | im ont aware of anythign related to "how do we mighate teh data if ovmf updates" | |
| 17:57:56 | tkajinam | ok | |
| 17:58:49 | tkajinam | I'll see if any public outcome can be found | |
| 17:58:53 | tkajinam | sean-k-mooney, thanks for that info ! | |
| 17:59:15 | sean-k-mooney | what im tryign to avoid is the need to have a glance iamge property or flavor extra spec for persictence other then the ephermal firmware flag | |
| 17:59:41 | sean-k-mooney | basiclaly if you want ephermal firmware i think you shoudl opt into it | |
| 18:00:16 | sean-k-mooney | otherwise we shoudl treat the tpm and nvram data as user data and persitit it | |
| 18:00:43 | sean-k-mooney | i have no idea where we woudl eventually store it for shleve but that a future us problem | |
| 18:02:22 | sean-k-mooney | orginally i was hopign the tpm and nvram files would be small enough to be able to store as secrete in barbican in teh future | |
| 18:02:37 | sean-k-mooney | but that was just an idea not something i looked into | |
| 18:03:37 | sean-k-mooney | the nvram and tpm data is privlaged enouch that i woudl not be comfrotable storign it in glance unless it was encypted | |
| #openstack-nova - 2026-01-20 | |||
| 09:26:32 | opendevreview | Taketani Ryo proposed openstack/nova master: mem-enc: refactor memory encryption trait logic for extensiblity https://review.opendev.org/c/openstack/nova/+/967971 | |
| 09:26:32 | opendevreview | Taketani Ryo proposed openstack/nova master: mem-enc: stop using _get_mem_encryption_config() for SEV checks https://review.opendev.org/c/openstack/nova/+/967970 | |
| 09:26:33 | opendevreview | Taketani Ryo proposed openstack/nova master: mem-enc: refactor _guest_configure_mem_encryption() for extensibility https://review.opendev.org/c/openstack/nova/+/967973 | |
| 09:26:33 | opendevreview | Taketani Ryo proposed openstack/nova master: mem-enc: make RP creation independent of specific encryption models https://review.opendev.org/c/openstack/nova/+/967972 | |
| 09:26:34 | opendevreview | Taketani Ryo proposed openstack/nova master: mem-enc: introduce a check between mem_encryption and locked_memory https://review.opendev.org/c/openstack/nova/+/971300 | |
| 09:26:34 | opendevreview | Taketani Ryo proposed openstack/nova master: mem-enc: adjust requirement checks for mem_encryption guests https://review.opendev.org/c/openstack/nova/+/967974 | |
| 11:14:17 | opendevreview | Serhii Ivanov proposed openstack/nova master: Add Linux bridge support to `network_data.json` https://review.opendev.org/c/openstack/nova/+/973924 | |
| 13:05:06 | opendevreview | Serhii Ivanov proposed openstack/nova master: Add Linux bridge support to `network_data.json` https://review.opendev.org/c/openstack/nova/+/973924 | |
| 14:12:41 | opendevreview | Johannes Kulik proposed openstack/nova master: Attaching a volume returns HTTP 202 https://review.opendev.org/c/openstack/nova/+/971068 | |
| 14:14:30 | opendevreview | Takashi Kajinami proposed openstack/nova master: Replace obsolete PCRE packages https://review.opendev.org/c/openstack/nova/+/970063 | |
| 14:17:02 | opendevreview | Takashi Kajinami proposed openstack/placement master: Replace obsolete PCRE packages https://review.opendev.org/c/openstack/placement/+/970068 | |
| 14:18:24 | opendevreview | Serhii Ivanov proposed openstack/nova master: Add Linux bridge support to `network_data.json` https://review.opendev.org/c/openstack/nova/+/973924 | |
| 14:19:47 | opendevreview | Takashi Kajinami proposed openstack/python-novaclient master: Replace obsolete PCRE packages https://review.opendev.org/c/openstack/python-novaclient/+/970066 | |
| 14:36:22 | opendevreview | Zhan Zhang proposed openstack/nova-specs master: Refine network setup procedure in live migrations https://review.opendev.org/c/openstack/nova-specs/+/970298 | |
| 14:52:10 | tkajinam | sean-k-mooney bauzas gibi, if you are around, could you review https://review.opendev.org/c/openstack/python-novaclient/+/973846 to fix py313 job ? | |
| 14:52:34 | tkajinam | the same bindep update was made in nova repo earlier by https://review.opendev.org/c/openstack/nova/+/970011 ... | |
| 14:52:39 | sean-k-mooney | tkajinam: sure i was trying to decied what to start next thats as good as anything else | |
| 14:52:54 | bauzas | done | |
| 14:53:00 | bauzas | sorry pretty busy this afternoon with meetings | |
| 14:53:04 | gibi | double done | |
| 14:53:05 | bauzas | but I've +2d it | |
| 14:53:07 | gibi | :D | |
| 14:53:20 | sean-k-mooney | ok i wont bother | |
| 14:53:22 | gibi | :) | |
| 14:53:38 | sean-k-mooney | the one think i was going to say is while we generally use whereto for the doc redirect | |
| 14:53:49 | sean-k-mooney | its a dep that is minimally maintained in oslo | |
| 14:53:56 | tkajinam | bauzas gibi sean-k-mooney, thanks all ! | |
| 14:53:57 | tkajinam | yeah | |
| 14:54:07 | sean-k-mooney | so long term we may consider droping it but i dont knwo what woudl replce it | |
| 14:54:16 | sean-k-mooney | we seam to have got lucky as well | |
| 14:54:29 | sean-k-mooney | there are some pcre regex changes with v2 | |
| 14:54:37 | sean-k-mooney | but we dont seam to be useign anything that chageds | |
| 14:54:42 | tkajinam | I even wonder if we need to maintain these redirects nowadays | |
| 14:54:43 | sean-k-mooney | *changed | |
| 14:55:14 | tkajinam | I've checked the repos using whereto but I've seen that all redirects were added in old days ( multiple years ago ) | |
| 14:55:21 | sean-k-mooney | ya not sure. while this isnt flat out broken there is no point it remvoing it | |
| 14:55:34 | tkajinam | yeah | |
| 14:55:39 | sean-k-mooney | but we can cross that bridge if we get there | |
| 14:57:42 | sean-k-mooney | gibi: bauzas https://review.opendev.org/c/openstack/nova/+/970063 and https://review.opendev.org/c/openstack/placement/+/970068 are the nova and placement version of the same patch | |
| 14:59:34 | tkajinam | sean-k-mooney, no that's a different one | |
| 14:59:58 | tkajinam | the patch I posted first is the one to limit installation of pcre(3) to docs job so that it won't be installed in py313 job running on Trixie | |
| 15:00:26 | tkajinam | the links you posted is the one to replace pcre(3) by pcre2 so that docs job can be migrated to newer Ubuntu/Debian which does not ship pcre3 | |
| 15:00:39 | tkajinam | or even RHEL/CentOS Stream 10 which replaced pcre by pcre2 | |
| 15:01:07 | tkajinam | (these all are about obsolete PCRE packages, though | |
| 15:01:19 | sean-k-mooney | they are related by ya your right they are slightly different | |
| 15:01:24 | tkajinam | yup | |
| 15:01:33 | sean-k-mooney | the josb are still runing but the docs jobs have passed already | |
| 15:01:51 | sean-k-mooney | those are also depenenton the reqirement patch and it looks like swift is failing | |
| 15:02:09 | sean-k-mooney | so less urgent since the depencies need to be resolved first | |
| 15:03:21 | tkajinam | the requirements update is now blocked by cross-job-swift but its fix is already up for review (and waiting for swift cores) | |