Earlier  
Posted Nick Remark
#openstack-nova - 2026-07-29
15:10:59 ralonsoh this is why in dpdk we disable live_migration_wait_for_vif_plug
15:11:05 sean-k-mooney no
15:11:21 ralonsoh let's focus on the kernel datapath
15:11:23 sean-k-mooney for dpdk we shoudl not reuire that
15:11:56 sean-k-mooney ok well the ovs agent regardless of the kerle or dpdk
15:12:13 sean-k-mooney is not allowed to depen on osprot being set to a non -1 value
15:12:15 sean-k-mooney https://github.com/openstack/neutron/commit/7ebcce0b8dcd4cd482da92672f5ae7c51530a429
15:12:21 sean-k-mooney is likely a regression
15:12:52 sean-k-mooney well maybe not
15:13:10 sean-k-mooney ``network-vif-plugged`` shoudl be sent when osport is -1
15:13:57 ralonsoh we have never done this
15:14:25 sean-k-mooney we never depened on the ofport out side of the openflow security group driver
15:14:45 sean-k-mooney so if you use ip tbales ofport was never reuqired
15:15:11 sean-k-mooney and even with the ovs firewall driver we just defered the security gorup flwo setup
15:15:58 ralonsoh but regardless of the FW setup, that is done after the port receives a valid ofport
15:16:10 sean-k-mooney it wasnt in the past
15:16:40 ralonsoh I pushed this https://review.opendev.org/c/openstack/neutron/+/992423 1 month ago
15:16:42 sean-k-mooney the tap is created befor ethe vm is unpased by the way
15:16:47 ralonsoh (related to the previous patch)
15:16:48 sean-k-mooney but not a lot before it
15:17:53 ralonsoh yes, but the TAP is created by libvirt, and that requires the vif-plugged event
15:18:03 ralonsoh I really don't know how this could work now
15:18:21 sean-k-mooney no the vif plugged event does not depend on the tap exsiting in general
15:18:39 ralonsoh without the TAP, the ofport=-1
15:18:41 ralonsoh right?
15:18:46 sean-k-mooney yes
15:18:48 sean-k-mooney and that is valid
15:18:51 ralonsoh so yes, it depends
15:19:07 ralonsoh until we have a valid ofport, Neutron does not send vif-plugged
15:19:19 sean-k-mooney ml2/ovs need to supprot seting network-vif-plugged with ofport=-1
15:19:29 sean-k-mooney then that is a regression in neutron
15:19:39 ralonsoh we never did that before
15:19:42 sean-k-mooney yes we di
15:19:43 ralonsoh this could not be a regression
15:19:49 sean-k-mooney for a very very very long time
15:20:11 ralonsoh no no, hold on
15:20:13 sean-k-mooney this is how dpdk has worked for ever
15:20:24 ralonsoh I really need to understand how it could work now
15:20:36 ralonsoh because is working randonly, most of the times
15:20:48 sean-k-mooney https://github.com/openstack/neutron/commit/7fd2725cb14b81f442eb57a38755829270ff2c43
15:21:57 ralonsoh ok, I need to review this patch too (I remember it)
15:22:10 ralonsoh I think this is working by accident
15:22:26 opendevreview Philipp Dreesens proposed openstack/nova-specs master: Add spec for bidirectional RPC liveness handshake https://review.opendev.org/c/openstack/nova-specs/+/984384
15:22:28 ralonsoh --> The network-vif-plugged during live migration was sent by the SOURCE agent calling update_device_up (for the existing binding that's still active on the source), NOT by the destination agent.
15:23:11 sean-k-mooney that shoudl not happen becuse we set migrating_to
15:23:14 sean-k-mooney in the port profiel
15:23:23 ralonsoh I know, I changed this code
15:24:39 sean-k-mooney and only the host named there is ment to send it with yes you updated that code
15:25:56 ralonsoh sean-k-mooney, thanks a lot, I need to recheck the recent changes in the OVS agent
15:26:11 ralonsoh (done by me, trying to fix other issues)
15:32:18 sean-k-mooney as an aside "``os_vif_delegation=True`` and ``create_port=True``" will mena the tap is create before we add the ovs port
15:32:37 sean-k-mooney so in that case we wont see -1 for kernel ovs but we still will for dpdk
15:32:54 sean-k-mooney os we shoudl not have divergent code paths if we can aovid it and just alwasy supprot -1
15:38:45 ralonsoh but isn't supporting ofport=-1 something wrong?
15:39:14 ralonsoh with ``create_port=True``, when the port is created? who creates it?
15:40:45 ralonsoh I need to leave now, I'll check this chat later. I'll also review the current OVS agent code
15:42:22 sean-k-mooney not in general. with create_port=True its not required
15:42:34 sean-k-mooney for kernel ovs
15:44:52 sean-k-mooney this is not the first time we have had to revert skipping prot wot ofprot=-1 https://github.com/openstack/neutron/commit/f1fa9529ee6753e2a3f47e4a6eb0286118520d25
21:44:41 opendevreview Goutham Pacha Ravi proposed openstack/nova master: Allow rebuild for instances with virtiofs shares https://review.opendev.org/c/openstack/nova/+/999048
22:12:20 opendevreview Ghanshyam Maan proposed openstack/nova master: Task tracking mechanism for graceful shutdown https://review.opendev.org/c/openstack/nova/+/996299
22:21:48 gmaan melwitt: thanks for review, ^^ updated the wrapper cache feedback. To make revert_resize better in shutdown, we need more work on some RPC redesign or so. I added the details in gerrit and reported a separate bug for tracking it for graceful shutdown part-3 or something to fix as a separate bug https://bugs.launchpad.net/nova/+bug/2162090
22:22:35 gmaan we need to make revert_resize more sync between source and dest compute like live migration or other operations which involves two compute
22:45:30 melwitt gmaan: ack thanks
22:46:55 opendevreview Ghanshyam Maan proposed openstack/nova master: Call manager graceful_shutdown while RPC server waits https://review.opendev.org/c/openstack/nova/+/996583
#openstack-nova - 2026-07-30
06:28:42 opendevreview Goutham Pacha Ravi proposed openstack/nova master: Allow rebuild for instances with virtiofs shares https://review.opendev.org/c/openstack/nova/+/999048
07:39:49 ralonsoh sean-k-mooney, please, ping me whenever you have some time (https://bugs.launchpad.net/nova/+bug/2161894/comments/5)
07:40:13 opendevreview Joan Gilabert proposed openstack/nova master: Report OWNER_NOVA trait on resource providers https://review.opendev.org/c/openstack/nova/+/994299
07:40:13 opendevreview Joan Gilabert proposed openstack/nova master: Add libvirt driver MDEV ARQ support for Cyborg https://review.opendev.org/c/openstack/nova/+/995840
09:25:18 opendevreview Anton Iacobaeus proposed openstack/nova master: libvirt: Generalize memory encryption config https://review.opendev.org/c/openstack/nova/+/998466
09:25:18 opendevreview Anton Iacobaeus proposed openstack/nova master: libvirt: Add memory encryption config for TDX https://review.opendev.org/c/openstack/nova/+/998608
09:25:19 opendevreview Anton Iacobaeus proposed openstack/nova master: libvirt: Launch security Intel TDX https://review.opendev.org/c/openstack/nova/+/999249
10:38:59 opendevreview Kamil Sambor proposed openstack/nova master: Add regression test for BFV evacuate + Cinder timeout https://review.opendev.org/c/openstack/nova/+/999261
13:28:08 gibi bauzas: have you seen compile_mdev_samples step hanging in devstack? It seems to me it causing the nova-whitebox job to time out here https://zuul.opendev.org/t/openstack/build/db30a8569196402898d754be9ce85426/log/job-output.txt#33470
13:28:23 gibi (or I'm not sure how knows more about that step)
13:28:41 bauzas hmmm, nope
13:30:15 gibi so far this is a single data point. I will report a bug if I see it happening multiple times
13:31:39 bauzas gibi: hmmm, when looking at the build logs, I see the samples created correctly
13:33:10 bauzas I can read "
13:33:10 bauzas 2026-07-30 09:14:57.345940 | controller | [3695 Async compile_mdev_samples:43255]: finished compile_mdev_samples with result 0 in 78 seconds
13:33:10 bauzas "
13:35:10 gibi are we looking at the same logs?
13:35:11 gibi 2026-07-30 09:24:02.142618 | compute-host | [3806 Async compile_mdev_samples:29935]: Waiting for completion of compile_mdev_samples running on PID 29935 (2 other jobs running)
13:35:16 gibi 334712026-07-30 09:24:02.182165 | compute-host | [3806 Async compile_mdev_samples:29935]: Signaling child to exit
13:35:19 gibi 334722026-07-30 09:24:03.318037 | compute-host | + inc/async:async_inner:64 : rc=0
13:35:22 gibi 334732026-07-30 09:24:03.363702 | compute-host | [35342 Async configure_neutron_nova:35342]: finished successfully
13:35:25 gibi 334742026-07-30 12:01:31.411526 | RUN END RESULT_TIMED_OUT: [untrusted : opendev.org/openstack/tempest/playbooks/devstack-tempest.yaml@master]
13:35:34 gibi this shows at 09:24:02 that it starts compiling
13:35:45 bauzas I'm looking at https://zuul.opendev.org/t/openstack/build/db30a8569196402898d754be9ce85426/log/job-output.txt#33470
13:35:49 gibi so this is not the same compilation that finishes at 09:14
13:36:09 bauzas ah I see
13:36:20 gibi so on the controller it finished ot 09:14 but on the compute-host it just start at 09:24
13:37:29 bauzas it was queued
13:37:36 bauzas but not started AFAICS
13:39:27 bauzas with the controller, we see the thread awaken up here https://zuul.opendev.org/t/openstack/build/db30a8569196402898d754be9ce85426/log/job-output.txt#16760
15:04:59 jgilaber melwitt, sean-k-mooney hi I'm seeing some failures on the functional test from my patch adding the OWNER_NOVA trait that I don't quite understand
15:05:33 jgilaber the tests worked fine in patchset 10, and after what I thought were mostly cosmetic change they are failing apparently randomly https://review.opendev.org/c/openstack/nova/+/994299/10..13
15:05:52 jgilaber e.g https://zuul.opendev.org/t/openstack/build/46982818a76243dfa64f66aaa34c2ef3 only one test fails but I see no error
15:06:34 jgilaber and in the same buildset the py313 job failed with different tests https://zuul.opendev.org/t/openstack/build/46982818a76243dfa64f66aaa34c2ef3
15:07:49 jgilaber sorry wrong link, I wanted to paste https://zuul.opendev.org/t/openstack/build/1b76d14e3a7a48278e4d8b84027e546b

Earlier   Later