| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2026-07-20 | |||
| 16:05:22 | opendevmeet | Removing item from minutes: #info Uggla has updated Launchpad and the above doc. Please ping me if you spot something missing. | |
| 16:05:22 | bauzas | #undo | |
| 16:05:30 | bauzas | #info Uggla has updated Launchpad and the above doc. Please ping him if you spot something missing. | |
| 16:05:44 | bauzas | #info Starting: https://etherpad.opendev.org/p/nova-2026.2-status#L16 interesting bugs to review. | |
| 16:05:52 | bauzas | anything to discuss about the statuses ? | |
| 16:06:29 | bauzas | kk | |
| 16:06:34 | bauzas | #topic Stable Branches | |
| 16:06:41 | bauzas | elodilles: your time :) | |
| 16:06:45 | elodilles | thanks :) | |
| 16:06:48 | elodilles | #info placement stable/2025.1 is blocked - workaround: https://review.opendev.org/c/openstack/placement/+/992299 | |
| 16:06:57 | elodilles | #info other stable gates should be OK | |
| 16:07:25 | bauzas | approved the workaround | |
| 16:07:27 | elodilles | sean-k-mooney's backports fixed stable/2025.1 nova gate. thanks all o/ | |
| 16:07:41 | elodilles | bauzas: thanks!!!! \o/ | |
| 16:07:47 | bauzas | anything else ? | |
| 16:08:01 | elodilles | only this one: | |
| 16:08:04 | elodilles | #info stable branch status / gate failures tracking etherpad: https://etherpad.opendev.org/p/nova-stable-branch-ci | |
| 16:08:07 | elodilles | :) | |
| 16:08:12 | elodilles | bauzas: back to you | |
| 16:08:17 | bauzas | k | |
| 16:08:22 | bauzas | #topic vmwareapi 3rd-party CI efforts Highlights | |
| 16:08:28 | bauzas | fwiesel: around ? | |
| 16:08:33 | fwiesel | Hi | |
| 16:08:52 | bauzas | o/ | |
| 16:09:00 | fwiesel | Yes, I looked into the pipeline failures, and instance creations were slowed down to that extend that no instances were being created. | |
| 16:09:32 | fwiesel | #link https://review.opendev.org/c/openstack/oslo.vmware/+/997269 | |
| 16:10:01 | fwiesel | This should reduce the overhead of doing api calls against VSphere, but I am suspecting it is not the full picture. | |
| 16:10:09 | fwiesel | Still digging into it. | |
| 16:10:13 | fwiesel | That's from my side. | |
| 16:11:24 | bauzas | cool thanks | |
| 16:11:31 | bauzas | #topic Kamil's news about eventlet removal | |
| 16:11:41 | bauzas | sambork ? | |
| 16:11:52 | sambork | o/ | |
| 16:12:20 | sambork | last week was dominated by test stabilization: the unit test exclude list is gone, and there's a push to make the threading functional CI job voting. | |
| 16:12:53 | gibi | e.g. https://bugs.launchpad.net/nova/+bug/2161293 ^^ | |
| 16:13:07 | sambork | he code cleanup is moving forward by replacing Nova-internal threading utilities with futurist primitives (both nova and futurist patch are pushed and ready for review) | |
| 16:13:31 | sambork | eom | |
| 16:13:51 | sambork | anything to add gibi? (thanks for bug above) | |
| 16:14:14 | gibi | fwiesel's finding is sort of eventlet related and I made mental note about performanc of the oslo retry decorator that could effect nova as well not just oslo.vmware | |
| 16:14:38 | gibi | we might want to take a hard look of the usage of that and consider tenacity's cheaper retry all over the place | |
| 16:15:32 | gibi | aaand I still haven't filed the bug to switch the default of our unit test execution to threading and just keep one tox job for unit test + eventlet | |
| 16:15:47 | bauzas | that's nice we no longer have unit test exclude list | |
| 16:15:47 | gibi | but I will I promise... eventually... | |
| 16:16:20 | gibi | btw the functional threading job has only 2 test case excluded | |
| 16:16:26 | bauzas | nice | |
| 16:16:42 | gibi | and at least I understand the problem in one of them :): | |
| 16:16:45 | bauzas | nice | |
| 16:17:30 | sambork | do we need additional ticket for checking retries? and do we wan to priorities this? | |
| 16:17:52 | gibi | sambork: please file a bug just to not forget it | |
| 16:17:59 | gibi | right now I don't feel it has a high prio | |
| 16:18:09 | sambork | ack | |
| 16:18:17 | gibi | but it might become one based on performance results from downstream testing | |
| 16:19:00 | opendevreview | Merged openstack/nova master: Use domain capabilities to detect SEV-SNP support https://review.opendev.org/c/openstack/nova/+/996316 | |
| 16:19:13 | opendevreview | Merged openstack/nova master: Extend tests for _is_supported_mem_encryption_model helper https://review.opendev.org/c/openstack/nova/+/997663 | |
| 16:19:26 | opendevreview | Merged openstack/nova master: Refactor CPU traits functional tests for AMD SEV support https://review.opendev.org/c/openstack/nova/+/997635 | |
| 16:19:34 | gibi | that is basically the report for the SNP status ^^^ :) | |
| 16:19:49 | antia | perfect timing :) | |
| 16:19:52 | gibi | yeah | |
| 16:19:59 | gibi | we can move on | |
| 16:20:39 | bauzas | ack | |
| 16:20:45 | bauzas | #topic Nova using openstack sdk for neutron | |
| 16:20:49 | bauzas | who is leading that ? | |
| 16:21:20 | elodilles | this is Lajos' topic if i'm not mistaken and he is still on PTO | |
| 16:21:32 | bauzas | cool moving on then | |
| 16:21:54 | bauzas | #topic Ironic review priorities | |
| 16:21:59 | bauzas | anything to say ? | |
| 16:23:43 | bauzas | looks not | |
| 16:23:48 | bauzas | #topic Confidential computing, status of SNP and TDX features | |
| 16:23:53 | bauzas | I've seen good news | |
| 16:24:27 | tkajinam | the remaining sev-snp patches lust landed so sev-snp support was completed | |
| 16:24:33 | tkajinam | \o/ | |
| 16:24:40 | gibi | \o/ | |
| 16:24:44 | tkajinam | I just noticed that https://blueprints.launchpad.net/nova/+spec/amd-sev-snp-libvirt-support is not yet approved. can someone do so ? | |
| 16:24:54 | tkajinam | then I'd update its implementation status | |
| 16:25:24 | gibi | done | |
| 16:25:27 | antia | I suppose the same for https://blueprints.launchpad.net/nova/+spec/intel-tdx-libvirt-support | |
| 16:26:31 | antia | anyway I ended up with PTO last week so not much on TDX side | |
| 16:26:31 | tkajinam | because these changes were merged tdx needs another rebase but I think we are now fully ready to start it. | |
| 16:26:38 | gibi | antia: fixed the bp for that too | |
| 16:26:48 | antia | gibi: thanks! | |
| 16:27:08 | gibi | I will grab a TDX hardware this week (hopefully) | |
| 16:27:22 | antia | started with some catch up with SNP and rebased with master, noticed some changes to the test structure which results in errors for me | |
| 16:27:29 | antia | I suspect it’s because the exists mock that was dropped in https://review.opendev.org/c/openstack/nova/+/994343/18/nova/tests/fixtures/libvirt.py | |
| 16:27:36 | antia | Since this is the error "Exception: This test invokes builtins.open on /sys/module/kvm_intel/parameters/tdx. It is bad, you should mock it." | |
| 16:28:00 | antia | gibi: Cool! Will get you something to test :) | |
| 16:29:17 | antia | In the end the sys fs check is not needed for TDX since Libvirt does it anyway so the easy fix is probably to drop it, but mostly curious if it was solved in some other way for SEV | |
| 16:29:36 | gibi | antia, tkajinam re mock, yeah we should either mock open or have a different way to check the status | |
| 16:29:52 | gibi | tkajinam: did we fully removed the reliance on the kernel module parameter? | |
| 16:30:17 | gibi | if so, and that worked for SNP, I hope we can do the same for TDX as well | |
| 16:30:33 | tkajinam | gibi, no we have to rely on it for snp but we can drop it for tdx | |
| 16:30:49 | gibi | tkajinam: due to the ES/SNP CVE? | |
| 16:31:09 | tkajinam | no. due to libvirt not checking the flags for es and snp | |
| 16:31:19 | tkajinam | we could probably get rid of access to sev flag, though | |
| 16:31:42 | antia | I'll just drop it as part of the rebase and we should be good | |
| 16:31:46 | gibi | tkajinam: antia: so for TDX we could go with the domain capabilities route? | |
| 16:31:51 | tkajinam | I mean it only checks /sys/module/kvm_amd/parameters/sev and does not check /sys/module/kvm_amd/parameters/sev_es or /sys/module/kvm_amd/parameters/sev_snp | |
| 16:32:19 | tkajinam | gibi, yes, libvirt checks the tdx flag when it declares <tdx support='yes'/> | |
| 16:32:33 | antia | gibi: Yes exactly. Right now it does both the sys fs check and domain capabilities which is not needed | |
| 16:32:51 | gibi | cool then you can get rid of the problem by not relying on reading that file :) | |
| 16:33:15 | tkajinam | yeah using only domain capabilities simplifies the logic and tests largely | |