Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2025-11-04
20:34:08 Zhan[m] understood, thanks for the heads up. In this case I think I'll submit the spec before Dec 4 and I can open a PR in Q1 but it can definitely wait until the freeze is over.
20:44:46 sean-k-mooney well its better to submit it early not late as if it comes in mid to late q1 it will be unlikely to land this cycle
20:46:09 sean-k-mooney the offical release is Wednesday, April 1, 2026. freautre freeze is February 26, 2026
20:46:45 sean-k-mooney so fi you only puth the patch up for review in late january or early febuary we likely wont have time to review it
20:50:49 Zhan[m] Ok, I'll see if I can make it there, if not, what will be the next cycle?
#openstack-nova - 2025-11-05
05:41:31 opendevreview Masanori Kuroha proposed openstack/nova master: Copy applied provider config https://review.opendev.org/c/openstack/nova/+/948304
06:32:38 opendevreview Masanori Kuroha proposed openstack/nova master: Copy applied provider config https://review.opendev.org/c/openstack/nova/+/948304
09:01:50 mkuroha bauzas: gibi: sean-k-mooney: I’ve updated the feature that copies the applied provider config files. I’d appreciate it if you could review it when you have time. https://review.opendev.org/c/openstack/nova/+/948304
09:23:06 zigo gmaan: Since you wrote these tests, any idea what could have gone wrong? https://bugs.launchpad.net/nova/+bug/2130703
10:00:44 bauzas mkuroha: as said in the change, pease reprovide the spec for 2026.1 so we could reapprove it
10:09:49 mkuroha bauzas: I see, understood. I'll recreate it for the 2026.1 spec.
10:10:40 bauzas mkuroha: thanks, ping me again once you're done, just copy the file and add in the history section something like "2025.2: Approved; 2026.1: Reproposed"
10:10:52 bauzas should be quick
10:14:00 mkuroha ok! thanks.
10:18:00 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
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?

Earlier   Later