| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2026-01-26 | |||
| 16:28:48 | gibi | that is it from me | |
| 16:30:07 | Uggla | thanks gibi | |
| 16:31:52 | Uggla | #topic Open discussion | |
| 16:32:03 | Uggla | (erlon): https://bugs.launchpad.net/nova/+bug/1452641 Bug 1452641: Static Ceph mon IP addresses in connection_info can prevent VM startup | |
| 16:32:29 | Uggla | Not sure erlon is available. | |
| 16:33:43 | Uggla | seems not | |
| 16:33:56 | Uggla | Anything else you'd like to discuss ? | |
| 16:35:01 | sean-k-mooney | i have not looked at the bug but i assume this is related to the fact that if you chagne the mon ips it breaks the vms becuase the bdms are out of sync | |
| 16:35:18 | sean-k-mooney | we have already consier that to be operator error in the past rather then a bug | |
| 16:35:34 | tkajinam | sean-k-mooney, yeah I think that's a kind of long standing limitation | |
| 16:35:43 | sean-k-mooney | im not sayign we cant make it better just aht we also want to be able to start a vm if cidner if offline | |
| 16:35:49 | tkajinam | and vms should be migrated/shelved to get a new ips passed down from cinder | |
| 16:35:58 | sean-k-mooney | so we should not just rebind the voluem on every boot | |
| 16:36:22 | sean-k-mooney | tkajinam: ya that the normal workaround do a move op to update the connection info | |
| 16:36:32 | sean-k-mooney | we do have a nova manage command too | |
| 16:37:33 | tkajinam | I guess an annoying point is that we have to first make cinder to expose up-to-date ips in attachment records | |
| 16:37:38 | tkajinam | so that nova can pull the updated info | |
| 16:37:51 | tkajinam | but I can be wrong because I looked into it some time ago | |
| 16:38:05 | tkajinam | anyway I think we need erlon to understand what needs to be discussed further | |
| 16:38:34 | sean-k-mooney | well its also an issue for nova provisioned sotrage to a degree althogh if you update the cpeh.conf i think a hard reboot is enogh in that case | |
| 16:38:48 | tkajinam | ah yes. that's true | |
| 16:39:42 | Uggla | tkajinam, sean-k-mooney at least that first info that erlon look at. | |
| 16:39:54 | tkajinam | yup :-) | |
| 16:40:14 | Uggla | moving on ? | |
| 16:40:28 | Uggla | or you'd like to talk about something else ? | |
| 16:41:10 | Uggla | #topic Bug scrubbing | |
| 16:41:15 | Uggla | #info up to 204 | |
| 16:41:20 | Uggla | #link: https://etherpad.opendev.org/p/nova-bug-triage-roster | |
| 16:41:27 | Uggla | #info: I will assign a new round of bug tomorrow or Wednesday. | |
| 16:41:52 | Uggla | In the mean time does someone need to discuss about a specific bug ? | |
| 16:42:12 | Uggla | *needs | |
| 16:43:03 | gibi | sorry I lost most of the context on the previously assigned bugs | |
| 16:43:29 | Uggla | yep sorry about that. | |
| 16:43:48 | gibi | I think https://bugs.launchpad.net/nova/+bug/2115726 needs discussion | |
| 16:45:04 | gibi | right now if it is not a doc bug but a code bug then it is incomplete in a sense that I'm not sure what is the expected behavior of nova here | |
| 16:45:59 | gibi | I can reject [pci]device_spec={} but there is a lot of partial matches that need to be decide if valid or not like {address="0000"} | |
| 16:48:07 | Uggla | hum anyone has opinion on that ? | |
| 16:53:08 | Uggla | gibi I think we have some kinfd of checks for PCI devices ? | |
| 16:53:15 | tkajinam | I got the impression that we may start with rejecting empty thing while leaving the others as these could be "valid partial match", I guess | |
| 16:53:42 | gibi | tkajinam: what happens that these fields are basically act as filters | |
| 16:53:53 | gibi | so the empty filter list means all devices | |
| 16:54:32 | gibi | so for me it is logical how nova behaves today | |
| 16:54:41 | tkajinam | hmm ok | |
| 16:54:50 | gibi | removing just the empty filter list case feels strange to me | |
| 16:55:06 | gibi | especially if we keep {address=""} doing the same thing, meaning all devcie | |
| 16:55:09 | gibi | device | |
| 16:56:50 | gibi | {managed=false} also means all devices today | |
| 16:57:15 | gibi | as managed is not a filter config but a result enhancing config here | |
| 16:57:37 | gibi | it means all matching devices get the managed flag set to false | |
| 16:57:44 | Uggla | yep, that's plenty of these exceptions I guess. | |
| 16:57:50 | gibi | yeah it is complex | |
| 16:58:01 | gibi | we can say 0 partial match but then we loose valid use case I feel | |
| 16:58:11 | Uggla | ack | |
| 16:58:27 | gibi | like { "vendor_id":"8086", "product_id":"10ca", "address": "0000:07:"} | |
| 16:58:33 | Uggla | can we improve the doc somewhere ? | |
| 16:58:43 | gibi | I have VFs under 07 and I want to match all | |
| 16:59:29 | gibi | Uggla: we can improve the doc be descrbing the current behavior but then the todays behavior becomes the expected behavior and Sean disagrees | |
| 16:59:37 | gibi | a/be/by/ | |
| 17:00:13 | Uggla | if not I agree to close it at non fix, explaining that it is not "ideal" but hard to improve. | |
| 17:01:00 | tkajinam | maybe we could document the current behavior first and then discuss how it can be improved separately | |
| 17:01:28 | gibi | As other cores I silent I would say lets move on. It is not that important | |
| 17:01:50 | gibi | s/other cores I silent/ other cores are silent/ | |
| 17:01:59 | Uggla | ok, we can discuss this later as well in async mode. | |
| 17:02:05 | gibi | sure | |
| 17:02:14 | gibi | my question is in the last comment of the bug | |
| 17:02:31 | Uggla | because we are on the top of the hour, time to close. | |
| 17:02:43 | Uggla | Thanks for joining this meeting. Have a nice day/evening and see you next week. | |
| 17:02:48 | gibi | thanks Uggla | |
| 17:02:51 | Uggla | #endmeeting | |
| 17:02:51 | opendevmeet | Meeting ended Mon Jan 26 17:02:51 2026 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | |
| 17:02:51 | opendevmeet | Minutes: https://meetings.opendev.org/meetings/nova/2026/nova.2026-01-26-16.01.html | |
| 17:02:51 | opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/nova/2026/nova.2026-01-26-16.01.txt | |
| 17:02:51 | opendevmeet | Log: https://meetings.opendev.org/meetings/nova/2026/nova.2026-01-26-16.01.log.html | |
| 17:03:15 | elodilles | thanks o/ | |
| 17:15:50 | opendevreview | Merged openstack/nova stable/2024.2: libvirt: Skip unsupported firmware types https://review.opendev.org/c/openstack/nova/+/974409 | |
| 17:20:44 | opendevreview | Nisha Brahmankar proposed openstack/nova master: Fix exception handling in nova cache https://review.opendev.org/c/openstack/nova/+/974695 | |
| 19:12:59 | opendevreview | Balazs Gibizer proposed openstack/nova master: Libvirt event handling without eventlet https://review.opendev.org/c/openstack/nova/+/965949 | |
| 19:12:59 | opendevreview | Balazs Gibizer proposed openstack/nova master: Use an executor to delay STOPPED events https://review.opendev.org/c/openstack/nova/+/974445 | |
| 19:13:00 | opendevreview | Balazs Gibizer proposed openstack/nova master: Run nova-compute in native threading mode https://review.opendev.org/c/openstack/nova/+/965467 | |
| 19:13:00 | opendevreview | Balazs Gibizer proposed openstack/nova master: DNM:Test with oslo.vmware + compute eventlet removal patches https://review.opendev.org/c/openstack/nova/+/973468 | |
| 19:27:13 | opendevreview | Balazs Gibizer proposed openstack/nova master: [hacking]Do not mock threading.Event https://review.opendev.org/c/openstack/nova/+/971454 | |
| 19:27:13 | opendevreview | Balazs Gibizer proposed openstack/nova master: Libvirt event handling without eventlet https://review.opendev.org/c/openstack/nova/+/965949 | |
| 19:27:14 | opendevreview | Balazs Gibizer proposed openstack/nova master: Use an executor to delay STOPPED events https://review.opendev.org/c/openstack/nova/+/974445 | |
| 19:27:14 | opendevreview | Balazs Gibizer proposed openstack/nova master: Run nova-compute in native threading mode https://review.opendev.org/c/openstack/nova/+/965467 | |
| 19:27:15 | opendevreview | Balazs Gibizer proposed openstack/nova master: DNM:Test with oslo.vmware + compute eventlet removal patches https://review.opendev.org/c/openstack/nova/+/973468 | |
| 21:07:02 | opendevreview | Steve Baker proposed openstack/nova master: Add VNC console support for the Ironic driver https://review.opendev.org/c/openstack/nova/+/942528 | |
| 22:15:16 | opendevreview | Steve Baker proposed openstack/nova master: Use the correct name for the ironic check job https://review.opendev.org/c/openstack/nova/+/974781 | |
| 22:44:57 | opendevreview | melanie witt proposed openstack/nova master: DNM test https://review.opendev.org/c/openstack/nova/+/974792 | |
| #openstack-nova - 2026-01-27 | |||
| 06:30:30 | opendevreview | Takashi Kajinami proposed openstack/nova master: libvirt: Use firmware auto-selection by libvirt https://review.opendev.org/c/openstack/nova/+/969132 | |
| 06:33:23 | opendevreview | Takashi Kajinami proposed openstack/nova master: libvirt: Add capability to load smm feature from existing xml https://review.opendev.org/c/openstack/nova/+/969131 | |
| 06:33:40 | opendevreview | Takashi Kajinami proposed openstack/nova master: libvirt: Use firmware auto-selection by libvirt https://review.opendev.org/c/openstack/nova/+/969132 | |
| 07:39:19 | gokhan | hello folks, I want to get your thoughts about this patch https://review.opendev.org/c/openstack/nova/+/973750 . It seems https://github.com/openstack/nova/commit/5a55a78d510b86975f0f4f8f43ee1feef7206244#diff-47eb12598e353b9e0689707d7b477353200d0aa3ed13045ffd3d017ee7d9e753 commit resolves live migration pre migrate failure. Regarding the fixes in Bug #1899835 (Avoid volume rollback mismatches), which handles cleanup on destination when | |
| 07:39:19 | gokhan | pre_live_migration fails: I’ve observed that many live migration failures (like the one where a volume is in 'backing-up' status) could potentially be caught much earlier. Currently, if a volume is busy or in an unstable state, the failure often occurs during pre_live_migration, triggering the complex rollback logic we've been refining. Would it make sense to implement a proactive volume status check at the Nova API level (or early in th | |
| 07:39:20 | gokhan | e Conductor) before the RPC call to the destination node? | |
| 07:47:47 | gibi | gokhan: I agree that if there is a way to catch "bad" volume states early in the complex live migration process then that can decrease the likelyhood of a problematic rollback. | |
| 07:56:18 | gokhan | thanks gibi We have submitted a patch (https://review.opendev.org/c/openstack/nova/+/973750) for catching in api side. We would like to confirm if this is the recommended approach. | |
| 08:02:32 | gokhan | Since melwitt has previously worked on similar issues—specifically the 'Avoid volume rollback mismatches' patches—I would highly value her insights and comments on this matter to ensure we're aligned with the existing logic. | |
| 08:03:50 | gibi | gokhan: yeah, I'm reading you patch now... | |
| 08:04:47 | gokhan | thanks gibi :) | |
| 08:10:58 | gibi | gokhan: I think the direction is OK. I left comments about the test coverage, and pinged melwitt in the review | |