| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2026-08-04 | |||
| 14:48:53 | clif | I assume this check is only triggered if an amd cpu is detected | |
| 14:49:43 | sean-k-mooney | clif: yes the exact check is complicated as we are also checking if libvirt has supprot too | |
| 14:50:11 | tkajinam | I suspect that there are something patched properly in the tests which eventually let the driver code to read that path | |
| 14:50:18 | tkajinam | I've not yet identified that yet though | |
| 14:52:29 | sean-k-mooney | File "/home/zuul/src/opendev.org/openstack/nova/nova/virt/libvirt/driver.py", line 7913, in _get_mem_encryption_config | |
| 14:52:31 | sean-k-mooney | if not self._host.supports_mem_encryption: | |
| 14:52:42 | sean-k-mooney | so that the trigger right | |
| 14:52:53 | sean-k-mooney | _get_guest_config | |
| 14:53:03 | sean-k-mooney | is calling _get_mem_encryption_config | |
| 14:53:16 | sean-k-mooney | whic eventully calls the sev check | |
| 14:53:24 | sean-k-mooney | but that happing alwasy now | |
| 14:54:04 | sean-k-mooney | so a way to fix this is in the libvirt fixutre alwasy mock _kernel_supports_amd_sev | |
| 14:54:14 | sean-k-mooney | and save it in self | |
| 14:54:26 | sean-k-mooney | then you can set the return value as needed in the sev tests | |
| 14:55:30 | sean-k-mooney | most unit test shoudl not get as far as calling _kernel_supports_amd_sev but if they do just returning False by defualt shoudl be fine | |
| 14:55:56 | sean-k-mooney | and you can either disbale the mockign with a class var or save the refence to the mock so you can modify it for the test that do | |
| 14:57:30 | sean-k-mooney | https://github.com/openstack/nova/blob/39dc667a1f9a7c12814f5892b900462560b1a229/nova/virt/libvirt/host.py#L2097 | |
| 14:57:35 | sean-k-mooney | i think that is the new call | |
| 14:57:43 | sean-k-mooney | added in https://github.com/openstack/nova/commit/7dd0d6106bdcf9babb81d7b55fd775b543a6e9ad | |
| 15:02:12 | sean-k-mooney | tkajinam: https://github.com/openstack/nova/commit/7dd0d6106bdcf9babb81d7b55fd775b543a6e9ad#diff-319aeacd4767563ecfa85b0690ccb4dfbdc9ce39173d08058f14cdce764c5040L2728-L2741 | |
| 15:02:32 | sean-k-mooney | so actully it this fixutre change i think | |
| 15:03:30 | sean-k-mooney | the libvirt fixure used ot alwasy mock the calls to read those files | |
| 15:04:47 | sean-k-mooney | self.useFixture(fixtures.MonkeyPatch('os.path.exists', fake_exists)) was overlly broad | |
| 15:05:01 | sean-k-mooney | but you can do a much more targeted mock in the same place | |
| 15:06:32 | sean-k-mooney | self.kernel_sev = self.useFixture(fixtures.MockPatch('nova.virt.libvirt.host.Host._kernel_supports_amd_sev', return_value=False).mock | |
| 15:30:44 | tkajinam | sean-k-mooney, I avoided that fixture in the base class so that I don't have to un-patch it later in test cases where these should be detected properly, but I may have to recheck that approach. | |
| 15:31:28 | tkajinam | but I have to revisit that approach, I agree | |
| 15:31:52 | sean-k-mooney | you wont need to unpatch it just modify the mock that is saved in self | |
| 15:32:13 | sean-k-mooney | but ya i get the intent of remvoign the broad mock | |
| 15:40:05 | tkajinam | yup | |
| 15:41:07 | tkajinam | I'm too tired to dig into it now but will take a further look tomorrow. | |
| 15:41:52 | tkajinam | I guess open is not triggered in intel machine with kvm due to absence of that path (and os.path.exists is not poison-pilled | |
| 16:10:10 | opendevreview | Joan Gilabert proposed openstack/nova master: Report OWNER_NOVA trait on resource providers https://review.opendev.org/c/openstack/nova/+/994299 | |
| 16:10:10 | opendevreview | Joan Gilabert proposed openstack/nova master: Add libvirt driver MDEV ARQ support for Cyborg https://review.opendev.org/c/openstack/nova/+/995840 | |
| 16:11:54 | opendevreview | Elod Illes proposed openstack/nova stable/2025.1: [stable-only] Set skip-level grenade as voting https://review.opendev.org/c/openstack/nova/+/999742 | |
| 16:58:06 | gmaan | gibi: did you see me reply on thread pool executor unifying idea, https://review.opendev.org/c/openstack/nova/+/998571/comment/23f68a57_21843d10 | |
| 16:58:31 | gmaan | i mentioned 3 options to unify those, if you can check and which one is more alligned with what you are thinking about iut | |
| 18:44:14 | opendevreview | Joan Gilabert proposed openstack/nova master: Report OWNER_NOVA trait on resource providers https://review.opendev.org/c/openstack/nova/+/994299 | |
| 18:44:14 | opendevreview | Joan Gilabert proposed openstack/nova master: Add libvirt driver MDEV ARQ support for Cyborg https://review.opendev.org/c/openstack/nova/+/995840 | |
| 19:48:53 | opendevreview | Sebastian Krott proposed openstack/nova master: conductor: Clean up port-bindings for live migrations https://review.opendev.org/c/openstack/nova/+/978121 | |
| 19:48:54 | opendevreview | Sebastian Krott proposed openstack/nova master: network: Add host filtering to `cleanup_instance_network_on_host` https://review.opendev.org/c/openstack/nova/+/978122 | |
| 21:37:14 | opendevreview | Merged openstack/nova master: Stabilize test_failed_count_with_anti_affinity_violation https://review.opendev.org/c/openstack/nova/+/998001 | |
| 21:39:24 | opendevreview | Merged openstack/nova master: (2/2)Stabilize test_create_images_negative_invalid_state https://review.opendev.org/c/openstack/nova/+/997719 | |
| 23:08:20 | opendevreview | Goutham Pacha Ravi proposed openstack/nova master: DNM: Add virtiofs share attachment CI jobs https://review.opendev.org/c/openstack/nova/+/999772 | |
| #openstack-nova - 2026-08-05 | |||
| 03:12:00 | opendevreview | Goutham Pacha Ravi proposed openstack/nova master: DNM: Add virtiofs share attachment CI jobs https://review.opendev.org/c/openstack/nova/+/999772 | |
| 03:12:30 | opendevreview | Goutham Pacha Ravi proposed openstack/nova master: DNM: Add virtiofs share attachment CI jobs https://review.opendev.org/c/openstack/nova/+/999772 | |
| 04:15:10 | opendevreview | Takashi Kajinami proposed openstack/nova master: Stub kernel support check of AMD-SEV in tests https://review.opendev.org/c/openstack/nova/+/999780 | |
| 04:16:00 | opendevreview | Dr. Jens Harbott proposed openstack/nova master: DNM: Test unit tests on kvm https://review.opendev.org/c/openstack/nova/+/999729 | |
| 04:26:32 | opendevreview | Takashi Kajinami proposed openstack/nova master: DNM: Test unit tests on kvm https://review.opendev.org/c/openstack/nova/+/999729 | |
| 04:55:43 | opendevreview | Goutham Pacha Ravi proposed openstack/nova master: DNM: Add virtiofs share attachment CI jobs https://review.opendev.org/c/openstack/nova/+/999772 | |
| 04:56:57 | opendevreview | Goutham Pacha Ravi proposed openstack/nova master: DNM: Add virtiofs share attachment CI jobs https://review.opendev.org/c/openstack/nova/+/999772 | |
| 06:18:29 | opendevreview | Takashi Kajinami proposed openstack/nova master: Stub kernel support check of AMD-SEV in tests https://review.opendev.org/c/openstack/nova/+/999780 | |
| 06:18:30 | opendevreview | Takashi Kajinami proposed openstack/nova master: DNM: Test unit tests on kvm https://review.opendev.org/c/openstack/nova/+/999729 | |
| 07:26:05 | opendevreview | Takashi Kajinami proposed openstack/nova master: Stub kernel support check of AMD-SEV in tests https://review.opendev.org/c/openstack/nova/+/999780 | |
| 07:26:06 | opendevreview | Takashi Kajinami proposed openstack/nova master: DNM: Test unit tests on kvm https://review.opendev.org/c/openstack/nova/+/999729 | |
| 07:32:44 | gibi | gmaan: re threadpool, not yet, I will try to get to it today but there are higher prio things in front of it at the moment | |
| 07:40:50 | opendevreview | Balazs Gibizer proposed openstack/nova master: DNM: check tempest for instability https://review.opendev.org/c/openstack/nova/+/999378 | |
| 07:43:05 | bauzas | gibi: may I gently ask you for a short +W ? https://review.opendev.org/c/openstack/nova/+/999607 | |
| 07:44:56 | gibi | bauzas: done. Have you checked if a failing post copy live migration in this case leaves the instance on the source node in ACTIVE state and we leak nothing on the dest node? | |
| 07:45:36 | bauzas | gibi: at least I saw that by the tempest whitebox test, the instance is back to the source | |
| 07:45:47 | bauzas | https://review.opendev.org/c/openstack/whitebox-tempest-plugin/+/939498 | |
| 07:46:24 | gibi | OK, thanks | |
| 07:46:55 | bauzas | but I'll verify whether the instance is back ACTIVE for sure | |
| 07:51:29 | opendevreview | Kamil Sambor proposed openstack/nova master: libvirt: retry get_guest() on InstanceNotFound during post-copy VIF reattach https://review.opendev.org/c/openstack/nova/+/997380 | |
| 08:07:35 | mattcrees | Good morning! Would anyone be free to give me another review of my bugfix? https://review.opendev.org/c/openstack/nova/+/982660 | |
| 09:07:30 | opendevreview | Takashi Kajinami proposed openstack/nova master: Stub kernel support check of AMD-SEV in tests https://review.opendev.org/c/openstack/nova/+/999780 | |
| 09:07:30 | opendevreview | Takashi Kajinami proposed openstack/nova master: DNM: Test unit tests on kvm https://review.opendev.org/c/openstack/nova/+/999729 | |
| 09:33:40 | opendevreview | Takashi Kajinami proposed openstack/nova master: Stub kernel support check of AMD-SEV in tests https://review.opendev.org/c/openstack/nova/+/999780 | |
| 09:33:40 | opendevreview | Takashi Kajinami proposed openstack/nova master: DNM: Test unit tests on kvm https://review.opendev.org/c/openstack/nova/+/999729 | |
| 09:34:09 | tkajinam | hmm I was able to fix unit tests but am struggling to fix functional tests. I don't know why that patching of update_provider_tree is ignored ... | |
| 09:40:47 | opendevreview | Merged openstack/nova master: doc: Document postcopy incompatibility with vGPU live migration https://review.opendev.org/c/openstack/nova/+/999607 | |
| 11:06:54 | opendevreview | Merged openstack/osc-placement master: tox: Fix outdated functional test environments https://review.opendev.org/c/openstack/osc-placement/+/998825 | |
| 11:08:17 | opendevreview | Elod Illes proposed openstack/nova stable/2025.1: [stable-only] Set skip-level grenade as voting https://review.opendev.org/c/openstack/nova/+/999742 | |
| 11:14:48 | opendevreview | Merged openstack/osc-placement master: [tox] Use constraints for requirements in docs job https://review.opendev.org/c/openstack/osc-placement/+/998816 | |
| 11:16:38 | opendevreview | Merged openstack/osc-placement master: reno: Update master for unmaintained/2024.1 https://review.opendev.org/c/openstack/osc-placement/+/965495 | |
| 11:17:49 | opendevreview | Merged openstack/osc-placement master: Exclude tests directory from coverage calculation https://review.opendev.org/c/openstack/osc-placement/+/906665 | |
| 12:19:53 | opendevreview | Elod Illes proposed openstack/osc-placement stable/2026.1: [tox] Use constraints for requirements in docs job https://review.opendev.org/c/openstack/osc-placement/+/999813 | |
| 12:21:48 | opendevreview | Elod Illes proposed openstack/osc-placement stable/2025.2: [tox] Use constraints for requirements in docs job https://review.opendev.org/c/openstack/osc-placement/+/999814 | |
| 12:23:21 | opendevreview | Elod Illes proposed openstack/osc-placement stable/2025.1: [tox] Use constraints for requirements in docs job https://review.opendev.org/c/openstack/osc-placement/+/999815 | |
| 12:42:10 | jangutter[m] | Hi folks, we ran into an issue in one of our OpenStack clusters where the autoincrement ID in the nova.instance_system_metadata table ran into the max for the column size https://opendev.org/openstack/nova/src/branch/master/nova/db/main/models.py#L993 | |
| 12:42:10 | jangutter[m] | For now, we’re promoting that column to BigInteger, but I was wondering if there’s a process for reclaiming old ID’s and resetting the autoincrement? Our combination of massive amounts of instance properties plus churn in instance launches triggered this, but I was wondering if there’s a periodic maintenance step we’re missing. | |
| 12:42:31 | sean-k-mooney | jangutter[m]: your not the first | |
| 12:43:02 | sean-k-mooney | so we didnt do that to avoid the upgrade impact but we have considered doing that in the past | |
| 12:43:12 | sean-k-mooney | everntully we will need to do the same upstream | |
| 12:43:28 | sean-k-mooney | what we did for our old internal cloud | |
| 12:43:30 | jangutter[m] | [sean-k-mooney](https://matrix.to/#/@sean-k-mooney:matrix.org) I was literally calculating how soon folks like CERN or telcos would run into this! | |
| 12:43:42 | sean-k-mooney | was manually reindex the records in teh table | |
| 12:44:02 | sean-k-mooney | ya so our internal cloud hit this about 2-3 years ago | |
| 12:44:08 | jangutter[m] | We took down our DB and re-imported (since we could take the downtime) | |
| 12:44:12 | sean-k-mooney | melwitt had the pleasure of helping them fix it | |
| 12:45:05 | sean-k-mooney | i think we did somethign simialr we shuffled the row ids back to the start of the reange fillign the gaps and then reset the increment point | |
| 12:45:06 | jangutter[m] | But yeah, migrating the primary index is not to be taken lightly. | |
| 12:45:48 | sean-k-mooney | the way we woudl do that upstream woudl be to add a new column and index then later hava a contract migration to drop the old integer column | |
| 12:46:21 | sean-k-mooney | so you woudl do the expand schema migration ot add the new colume then upgrade nova then we woudl drop the old primary index column | |
| 12:47:15 | sean-k-mooney | jangutter[m]: i dont know how shareable or robust the scripting we did internaly was but i could see adding a nova-manage command to do this if it was safe to do so | |
| 12:48:14 | jangutter[m] | You’d still run out of indexes, but hopefully other things would bother you first (like the rise of the Zombie people in 2045) | |
| 12:48:14 | sean-k-mooney | but ya the instance system metadata table is the first to hit it because there are many entreis per vm | |
| 12:49:46 | jangutter[m] | Thanks for confirming! | |
| 12:50:15 | sean-k-mooney | im just checking if i have any refence ot the downstream issue its been a while | |
| 12:50:47 | jangutter[m] | Yeah, strangely I didn’t find any launchpad issues | |