| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2026-02-02 | |||
| 16:21:32 | gibi | Last week fwiesel reported issues from the compute eventlet removal series | |
| 16:21:56 | gibi | I'm fixed one problem https://review.opendev.org/c/openstack/nova/+/975172/5?usp=related-change | |
| 16:22:07 | opendevreview | Takashi Kajinami proposed openstack/nova master: AMD SEV: omit iommu='on' for virtio devices https://review.opendev.org/c/openstack/nova/+/909635 | |
| 16:22:14 | gibi | and found a deeper one https://review.opendev.org/c/openstack/nova/+/965467/48#message-62f7ef828c38c33f322f72737b4016ace9b9f242 | |
| 16:22:42 | bauzas | ack, will look at them | |
| 16:22:49 | gibi | The second is not resolved yet but I have plans to fix it | |
| 16:23:28 | gibi | other than that the improvement on the event delaying mechanism is now ready to (re)-review https://review.opendev.org/c/openstack/nova/+/974445/12 | |
| 16:23:48 | bauzas | yup, on my plan | |
| 16:23:50 | gibi | and I think that is it | |
| 16:23:59 | gibi | Uggla: mic is back to you | |
| 16:24:16 | gmaan | nice, I will check it. It was ok both way for me as i commented in that change | |
| 16:24:18 | gmaan | i saw the next change in that series where libvirt driver was canceling all the submitted event during shutdown which is better. | |
| 16:24:32 | Uggla | thanks gibi. | |
| 16:24:32 | gmaan | but I will check the latest change | |
| 16:24:55 | Uggla | #topic Open discussion | |
| 16:25:10 | erlon | hey Uggla | |
| 16:25:16 | erlon | hey today :) | |
| 16:25:22 | erlon | *here | |
| 16:25:37 | erlon | first, sorry about missing the previous meeting. I dropped in the topic but couldn't attend. | |
| 16:26:18 | erlon | I have a customer who wants this bug fixed. After some investigation, I concluded that what is currently affecting them is bug #1741364, which is a different manifestation of a similar problem: the VM devices not being updated if the Ceph monitors change during the virtual machines' lifetime. | |
| 16:26:51 | erlon | #link https://bugs.launchpad.net/nova/+bug/1452641 | |
| 16:27:09 | erlon | Bug #1741364 addresses the ephemeral part of it, while bug #1452641 deals with Cinder volume devices. | |
| 16:27:30 | erlon | #link launchpad.net/bugs/1741364 | |
| 16:28:03 | erlon | With that said, I want to get some feedback regarding a potential fix for the issue: https://review.opendev.org/c/openstack/nova/+/974032 | |
| 16:28:28 | erlon | I believe we don't need anything fancy; we just need to ensure that the ephemeral disk information is also updated whenever we do that for the RBD volumes. I think that change is close to what we need, but I was also considering whether it would be possible to patch nova-manage to allow batch operations, just like we do for volume attachments. | |
| 16:32:35 | erlon | so, I suppose nobody opposes :p | |
| 16:32:51 | gibi | :) | |
| 16:33:12 | Uggla | erlon, I guess everybody needs to load context too. | |
| 16:33:16 | tkajinam | so the point is that you don't want to stop and start the vm and looking for the way to update mon addrs keeping vms running ? | |
| 16:33:17 | bauzas | yeah | |
| 16:33:44 | tkajinam | if you stop and start the vm then I guess xml is regenerated and picks up the new mon addrs (correct me if I'm wrong) | |
| 16:34:40 | erlon | tkajinam: starting and stopping the VMs should be okay, actually I don't think should be possible to update the block device mapping without stopping. | |
| 16:35:22 | tkajinam | ah, ok | |
| 16:35:49 | erlon | tkajinam: so, that behaves like you're saying for the volume attachments. But if the virtual machine has ephemeral devices back it by RBD, those are not refreshed. The ask is to, make them behave like volumes. | |
| 16:37:43 | erlon | so, when you shelve, or migrate, you would get all volume mappings (cinder and ephemeral) updated (today only cinders are) | |
| 16:38:54 | tkajinam | sounds fair | |
| 16:38:55 | Uggla | erlon to my mind that sounds reasonable. I will add this patch to the review list. | |
| 16:39:57 | erlon | right, thanks. I will do a full review on it as well since I believe there's a few bits missing. And I'll propose something for nova-manage | |
| 16:40:26 | Uggla | ok | |
| 16:40:27 | erlon | nova-manage volume_attachment refresh --ephemeral [INSTANCE_UUID] [VOLUME_ID] [CONNECTOR_PATH] | |
| 16:40:27 | erlon | or | |
| 16:40:27 | erlon | nova-manage ephemeral_attachments refresh [INSTANCE_UUID] | |
| 16:40:45 | tkajinam | I'm wondering if a few other operations can resolve it. I feel like only providing live-migration to fix bdm would be incomplete from operator's perspective | |
| 16:41:56 | erlon | The first, would mix concepts (volume vs ephemeral), but in my opinion would make a smoother for the user experience. The second is more consistent, what would require more code and a new command | |
| 16:41:59 | tkajinam | (and we may want a similar functionality in cold migration path for example | |
| 16:43:11 | Uggla | erlon I would rather the second, but that's just a feeling. | |
| 16:43:44 | erlon | tkajinam: right, today, for volume we only have the functionality on migrate, resize and re-attach (shelve), are you thinking on something else? | |
| 16:45:25 | tkajinam | erlon, no the list looks good for start. if we extend it we also have to extend the refresh mechanism for cinder volumes, likely | |
| 16:46:55 | tkajinam | and I personally tend to support the 2nd approach given ephemeral volumes are handled slightly different from cinder volumes and I don't want to confuse users to find out which options can be used for resources | |
| 16:47:01 | tkajinam | for example volume id is not needed for ephemeral volumes | |
| 16:47:29 | Uggla | tkajinam ++ | |
| 16:47:51 | erlon | yeah, I also believe that the current operations should be okay, since it is mostly a point in time operation. As long as the operator have a way to update the VMs they should be fine. | |
| 16:47:51 | Uggla | erlon, something else ? | |
| 16:47:54 | erlon | ok | |
| 16:47:58 | gibi | sounds sane | |
| 16:47:58 | erlon | thats all from me | |
| 16:48:09 | Uggla | thanks erlon | |
| 16:48:28 | Uggla | I guess lajoskatona wanted to share someting ? | |
| 16:48:39 | lajoskatona | Uggla: thanks, I have :-) | |
| 16:49:07 | lajoskatona | o/ | |
| 16:49:28 | lajoskatona | I started to work on the migration away from neutronclient calls to SDK ones, and I have few patches up for review: | |
| 16:49:34 | lajoskatona | https://review.opendev.org/q/topic:%22sdk_for_neutron%22 | |
| 16:49:59 | lajoskatona | The last one for ports is red currently, I have to revisit it when I will have time | |
| 16:50:57 | lajoskatona | I tried to do small patches, each one covers one neutron API element, like networks or subnets | |
| 16:51:44 | lajoskatona | and it would be really helpful if I have feedback if the overall direction is good or any suggestion in review | |
| 16:51:55 | gibi | i will try to start reviewing them | |
| 16:52:31 | Uggla | me too. | |
| 16:52:42 | lajoskatona | thanks. I believe teh logic under remained the same, I just changed from what SDK returns instead of the dicts returned by neutronclient | |
| 16:53:27 | gibi | can we put a recurring topic about this on the agenda? | |
| 16:53:33 | lajoskatona | the other "big" difference are the exceptions as Neutronclient has some real exotic ones, and I tried to cover those with exceptions from SDK | |
| 16:53:39 | gibi | (just to help me remember) | |
| 16:54:02 | Uggla | gibi sure. | |
| 16:54:03 | lajoskatona | that can work, we do the same in Neutron meeting for this topic when I have more for review | |
| 16:54:16 | gibi | Uggla: thanks | |
| 16:54:38 | lajoskatona | thanks for the time | |
| 16:54:39 | Uggla | lajoskatona did you checked what was done for manila regarding sdk ? | |
| 16:55:14 | lajoskatona | yes, I checked in the past but not deeply | |
| 16:55:31 | MaxLamprecht[m] | o/ Uggla I have also one additional topic | |
| 16:56:09 | Uggla | MaxLamprecht[m] do you think you can cover it in 5mn ? | |
| 16:56:11 | lajoskatona | that's it from me for SDK | |
| 16:56:19 | Uggla | thanks lajoskatona | |
| 16:56:23 | MaxLamprecht[m] | sure | |
| 16:56:34 | Uggla | ok MaxLamprecht[m], so please go ahead | |
| 16:56:39 | MaxLamprecht[m] | I am working on resolving some inconsistencies between bdms/cinder-attachments that are happening regulary in our environment. | |
| 16:56:48 | MaxLamprecht[m] | I have these MRs incl. regression tests. Would be great to get review :) https://review.opendev.org/c/openstack/nova/+/972045 https://review.opendev.org/c/openstack/nova/+/974832 https://review.opendev.org/c/openstack/nova/+/934984 | |
| 16:58:21 | Uggla | MaxLamprecht[m], I have put them on the review list. | |
| 16:58:54 | Uggla | it looks like you have reproducer so it is cool | |
| 16:58:54 | MaxLamprecht[m] | I am currently investigating every single cause of these "out of sync" states in our env and try to fix the root causes. Maybe I will come up with more MRs in the next weeks/months. | |
| 16:58:56 | MaxLamprecht[m] | thanks | |
| 16:59:40 | Uggla | MaxLamprecht[m] something else to add ? | |
| 16:59:54 | MaxLamprecht[m] | nop thats everything :) thx | |
| 17:00:23 | Uggla | good thanks. It is time to close because we are at the top of the hour. | |
| 17:01:01 | Uggla | Thanks for joining this meeting. Have a nice day/evening and see you next week. | |
| 17:01:09 | Uggla | #endmeeting | |
| 17:01:09 | opendevmeet | Meeting ended Mon Feb 2 17:01:09 2026 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | |
| 17:01:09 | opendevmeet | Minutes: https://meetings.opendev.org/meetings/nova/2026/nova.2026-02-02-16.01.html | |
| 17:01:09 | opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/nova/2026/nova.2026-02-02-16.01.txt | |
| 17:01:09 | opendevmeet | Log: https://meetings.opendev.org/meetings/nova/2026/nova.2026-02-02-16.01.log.html | |
| 17:01:09 | gibi | thanks | |
| 17:01:15 | lajoskatona | Bye, o/ | |