| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2025-11-05 | |||
| 10:20:20 | mkuroha | bauzas: Thank you for the comment, I created: https://review.opendev.org/c/openstack/nova-specs/+/966151 | |
| 11:14:46 | opendevreview | Merged openstack/nova master: api: Pre-query not deleted members in server groups https://review.opendev.org/c/openstack/nova/+/959696 | |
| 11:15:54 | opendevreview | Merged openstack/nova master: setup: Remove pbr's wsgi_scripts https://review.opendev.org/c/openstack/nova/+/902688 | |
| 11:40:03 | opendevreview | Merged openstack/nova stable/2025.1: Update start_service() function in test https://review.opendev.org/c/openstack/nova/+/963845 | |
| 11:40:14 | opendevreview | Merged openstack/nova stable/2025.1: Adds regression test for bug LP#2085135 https://review.opendev.org/c/openstack/nova/+/963846 | |
| 12:25:07 | opendevreview | Merged openstack/nova stable/2025.1: Reset the mapped field of nodes at service deletion https://review.opendev.org/c/openstack/nova/+/963847 | |
| 12:26:24 | sean-k-mooney | Zhan[m]: if you have input on https://review.opendev.org/c/openstack/nova/+/966106/comment/80b6a2a0_591c5cab/ feel free to add to it | |
| 12:27:22 | sean-k-mooney | for context of others ^ is related to https://bugs.launchpad.net/nova/+bug/2128665 which is a very specific edgecase that results in live migration downtime when using calico | |
| 12:27:44 | sean-k-mooney | it could impact other backend but shoudl not impact ml2/ovs or recent version fo ml2/ovn | |
| 12:28:44 | sean-k-mooney | im conflcited on if this shoudl be fixed, if it should be fixed as a bug or as a feature to split post-live-migration into networking and the rest | |
| 12:52:33 | opendevreview | Masanori Kuroha proposed openstack/nova-specs master: Copy the spec approved in 2025.2 to 2026.1 https://review.opendev.org/c/openstack/nova-specs/+/966151 | |
| 14:00:01 | Zhan[m] | sean-k-mooney: Thanks, I will put comments there too. | |
| 14:02:06 | Zhan[m] | Just for my own understanding, because we are not using ovn: from what you describe, the ovn driver in some sense is not really depending on the port binding activation but via the RARP packet (which I assume will be sent as soon as the destination QEMU process is resumed)? | |
| 14:03:30 | Zhan[m] | calico is more of using the port binding activation as the trigger for switching the network to the dest QEMU so yes that's why we're hitting | |
| 14:11:06 | sean-k-mooney | Zhan[m]: so the ml2/ovs ml2/linuxbrige (before they deleted it) and as of about a year ago ml2/ovn driver | |
| 14:11:24 | sean-k-mooney | all wired up the port is there was a portbinidng for the host | |
| 14:11:30 | sean-k-mooney | not just an active one | |
| 14:11:42 | sean-k-mooney | for calico this si tricky because the tap does not exsit yet | |
| 14:12:21 | sean-k-mooney | Zhan[m]: hoever we coudl modify the supprot for vif_type=tap to create the tap in pre-live-migrtion | |
| 14:12:30 | sean-k-mooney | we are condiering doing that for ovn | |
| 14:12:39 | sean-k-mooney | becuse ovn while it strcitly sepaking does not need it | |
| 14:12:49 | sean-k-mooney | can take a long time to install the flow in larger clouds | |
| 14:13:20 | sean-k-mooney | basically whith many vm and port the ovn db perfromcen cna resulting in reconsitaion taking over 30s in some cases | |
| 14:14:07 | sean-k-mooney | Zhan[m]: we modifed ovn to allow the trafic swithc to be triggred by the RARP packet sent by qemu when the vm unpauses | |
| 14:14:40 | sean-k-mooney | Zhan[m]: for ml2/ovs and ml2/linux bridge because they relyied on mac learning the RARP is the only thing that cause the traffic to be rerouted | |
| 14:15:17 | sean-k-mooney | for calico that a bit harder becuase its an l3 backend so the mac learning frames are likely entirly ignored | |
| 14:15:49 | sean-k-mooney | Zhan[m]: if you wanted to improve downtime mroe in calico then using the RARP to triger the update would be a consitent approch | |
| 14:26:24 | Zhan[m] | Indeed it's tricky I think for l3 in general, thanks for the explanation. | |
| 14:27:46 | Zhan[m] | but wondering if ml2/ovs can switch traffic with the RARP, what is the role that the port binding is playing here? | |
| 14:28:15 | Zhan[m] | the way we use calico that i do see port bindings to the destination are created in pre live migraiton | |
| 14:29:26 | opendevreview | Julien LE JEUNE proposed openstack/nova stable/2024.2: Adds regression test for bug LP#2044235 https://review.opendev.org/c/openstack/nova/+/961602 | |
| 14:29:57 | opendevreview | Julien LE JEUNE proposed openstack/nova stable/2024.2: nova-conductor puts instance in error state https://review.opendev.org/c/openstack/nova/+/961775 | |
| 14:34:57 | opendevreview | Julien LE JEUNE proposed openstack/nova stable/2024.2: nova-conductor puts instance in error state https://review.opendev.org/c/openstack/nova/+/961775 | |
| 15:18:33 | opendevreview | Henry Richter proposed openstack/nova master: Preserve vTPM state between power off and power on https://review.opendev.org/c/openstack/nova/+/955657 | |
| 15:29:34 | opendevreview | Nicolai Ruckel proposed openstack/nova master: Preserve UEFI NVRAM variable store https://review.opendev.org/c/openstack/nova/+/959682 | |
| 15:40:59 | nicolairuckel | sean-k-mooney, thanks for your feedback. That fixed almost everything. | |
| 15:41:24 | nicolairuckel | I was so sure I already tried that but maybe that was before you told me that I need to recreate the VM. | |
| 15:41:30 | sean-k-mooney | cool ill pull in your updated code later in the week | |
| 15:41:36 | nicolairuckel | thanks | |
| 15:41:56 | sean-k-mooney | i tried the version i comment on but i didnt try removing the code i commened on | |
| 15:44:19 | nicolairuckel | I also had to revert my changes to one of the tests because the XML changed. | |
| 15:44:38 | nicolairuckel | That's fine, you shouldn't have to spend extra time on my mistakes. :D | |
| 15:45:00 | sean-k-mooney | well this is part of doing code review | |
| 15:45:12 | sean-k-mooney | makign sure we only change what needs to be changed | |
| 15:45:27 | sean-k-mooney | so its fine i have that devstack set up so ill test it when i have time | |
| 15:46:28 | sean-k-mooney | nicolairuckel: you left a coulpe of prints | |
| 15:46:38 | sean-k-mooney | https://review.opendev.org/c/openstack/nova/+/959682/9/nova/tests/functional/libvirt/test_uefi.py#61 | |
| 15:46:42 | sean-k-mooney | that shoudl be removed | |
| 15:47:43 | opendevreview | Balazs Gibizer proposed openstack/nova master: [CI]nova-alt-configurations tests eventlet https://review.opendev.org/c/openstack/nova/+/965922 | |
| 15:47:44 | opendevreview | Balazs Gibizer proposed openstack/nova master: Default native threading for sch, api and metadata https://review.opendev.org/c/openstack/nova/+/965924 | |
| 15:47:44 | opendevreview | Balazs Gibizer proposed openstack/nova master: Move monkey_patch from init to the entrypoints https://review.opendev.org/c/openstack/nova/+/965923 | |
| 15:48:07 | sean-k-mooney | nicolairuckel: im on a call so cant review realtime but skiming over it that was the only thing that imidatly jumped out to me | |
| 15:49:36 | nicolairuckel | oh, right | |
| 15:49:37 | nicolairuckel | thanks | |
| 15:50:14 | opendevreview | Nicolai Ruckel proposed openstack/nova master: Preserve UEFI NVRAM variable store https://review.opendev.org/c/openstack/nova/+/959682 | |
| 15:51:32 | opendevreview | Nicolai Ruckel proposed openstack/nova master: Preserve UEFI NVRAM variable store https://review.opendev.org/c/openstack/nova/+/959682 | |
| 16:02:07 | gmaan | zigo: ack, I will check that | |
| 16:02:23 | zigo | Cheers. | |
| 16:46:16 | opendevreview | Balazs Gibizer proposed openstack/nova master: Default native threading for sch, api and metadata https://review.opendev.org/c/openstack/nova/+/965924 | |
| 16:46:41 | gibi | dansmith: sean-k-mooney: ^^ this (and its ancestors) are fixed up now based on the yesterday's dicussion | |
| 17:02:30 | opendevreview | Nicolai Ruckel proposed openstack/nova master: Preserve UEFI NVRAM variable store https://review.opendev.org/c/openstack/nova/+/959682 | |
| 17:19:30 | opendevreview | Pavlo Shchelokovskyy proposed openstack/nova master: Implement placement:same_subtree flavor extra spec https://review.opendev.org/c/openstack/nova/+/966205 | |
| 17:32:13 | opendevreview | Merged openstack/nova-specs master: Copy the spec approved in 2025.2 to 2026.1 https://review.opendev.org/c/openstack/nova-specs/+/966151 | |
| 18:00:36 | melwitt | dansmith: I think I have to make more updates to the vTPM patches :( sean commented on the spec review about not having any new sys meta key for storing the TPM security policy https://review.opendev.org/c/openstack/nova-specs/+/961564/3/specs/2026.1/approved/vtpm-live-migration.rst#181, | |
| 18:01:51 | melwitt | in the flavor instead | |
| 18:01:51 | melwitt | in the current version, I still used a sys meta key to stash the policy because I was thinking of a scenario where the operator may want to disallow 'user' (legacy) vTPM instances and I had been thinking I needed to store it to know to add the USER required trait for scheduling (to prevent scheduling of 'user' if configured). but I guess I could just make the logic in the request filter add the USER trait if there is vTPM but no policy | |
| 18:03:49 | melwitt | dansmith: what do you think? | |
| 18:12:03 | dansmith | melwitt: ack, yeah I guess I thought we were still going to stamp it in the sysmeta regardless of where the decision came from, but I guess we can just make that "virtual" and always look at the flavor | |
| 18:12:17 | dansmith | I hate to have to revise it again and do my testing again, but.. yeah | |
| 18:13:20 | melwitt | dansmith: yeah, I'm getting confused thinking about it but I'm remembering now that was I was thinking was that we would need to be able to differentiate between a legacy vTPM instance vs a new defaulted 'user' vTPM instance, | |
| 18:14:44 | melwitt | because if the operator wanted to disallow new 'user' instances, I think they also wouldn't want to block pre-existing legacy instances from doing things like resize | |
| 18:14:47 | melwitt | in order to tell the difference between an old vTPM instance and a new defaulted one, we would have to store it in sys meta. that's why I did it | |
| 18:16:12 | melwitt | but sys meta is not viewable in the scheduler request filter ... so I'm not sure how that could be | |
| 18:19:27 | dansmith | well, before, we needed to know if they had opted into user or were being defaulted, so that we didn't migrate against their will, right? | |
| 18:19:40 | dansmith | but if we only change via resize then we don't need to know the difference.. user is user until resize and then it's not user | |
| 18:19:52 | dansmith | s/not/potentially not/ | |
| 18:21:37 | melwitt | yeah...thinking | |
| 18:23:31 | melwitt | this is another place where I see use of the sys meta key https://review.opendev.org/c/openstack/nova/+/941483/35/nova/virt/libvirt/driver.py#10803 if we want to be able to set the LibvirtLiveMigrateData fields to None for new defaulted instances | |
| 18:24:06 | melwitt | for the object backleveling check | |
| 18:24:42 | dansmith | right but you'll just do instance.flavor.get('security', 'user') above right? | |
| 18:24:50 | dansmith | oh, well, | |
| 18:25:03 | dansmith | you'll actually do something like: | |
| 18:25:22 | dansmith | istpm = instance.flavor.get('tpm_model', None) | |
| 18:25:51 | dansmith | if istpm: security = instance.flavor.get('security', None) else: security = None | |
| 18:25:56 | dansmith | and then the rest will be the same right? | |
| 18:28:40 | melwitt | it's confusing because I think you would only want to set those to None if the instance is new enough for the fields to be relevant ... or maybe that doesn't matter? | |
| 18:29:41 | dansmith | if it has a model but no security, then it's user | |
| 18:29:47 | dansmith | if it has a model and security, then $security | |
| 18:29:53 | melwitt | whether it's a legacy vTPM instance vs a new defaulted 'user' vTPM instance | |
| 18:30:04 | dansmith | if it has no model, then that's your None case, regardless of if it's new or old | |
| 18:30:48 | melwitt | hm yeah, ok. | |
| 18:31:09 | dansmith | I mean.. right? | |
| 18:31:58 | melwitt | yeah I had kept thinking we wouldn't want to set None if it's legacy, but I guess it doesn't really hurt anything or matter | |
| 18:32:24 | melwitt | in my mind it was like, "if legacy, don't do anything different than it is today" | |
| 18:32:57 | dansmith | no, legacy user and new user are the same AFAIK | |
| 18:33:01 | melwitt | i.e. it doesn't matter if we prevent backport of a live migrate object for legacy vTPM because it can't happen | |
| 18:33:47 | dansmith | well, technically user migrations can happen if the user is the one doing the migration (if the admin has granted them that right) so we should have that work right? | |
| 18:34:21 | dansmith | but like if I want to delegate live migrate ability to project manager role or something that should work | |
| 18:34:23 | melwitt | no, 'user' mimics legacy completely including not being live migratable | |
| 18:34:37 | dansmith | or if the user doing the migration has been granted access to the key in barbican, it should work fine right? | |