Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2025-11-04
20:04:06 Zhan[m] obviously the spec will come first
20:04:23 sean-k-mooney but ya spec first to fiutre out exaclty how it shoudl look
20:04:44 sean-k-mooney is this somehtin you think you would have time to work on this cycle
20:04:46 Zhan[m] ok let's start with the spec first, thanks for looking into this too!!
20:05:01 Zhan[m] I'll see and get back to you on this.
20:05:08 sean-k-mooney ack no worries
20:21:06 Zhan[m] Ok so I'll be working on the spec now and submit it soonish, but regarding the code (the refining part) may come later in Q1, consider we may have some back and forth in the spec.
20:21:56 Zhan[m] I'll put the goal of spec to be 1. this change 2. put networking bits in the right place.
20:26:36 sean-k-mooney Zhan[m]: we have selected december 4 or 8th for spec feeze
20:26:51 sean-k-mooney with feature freeze aroudn the middle fo febuary
20:27:02 sean-k-mooney just for context so you are not surpised
20:27:14 sean-k-mooney normally sepc freeze would be around january 8th
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: Move monkey_patch from init to the entrypoints https://review.opendev.org/c/openstack/nova/+/965923
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: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 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:01:51 melwitt in the flavor instead
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

Earlier   Later