Earlier  
Posted Nick Remark
#openstack-nova - 2026-07-29
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
15:07:55 melwitt jgilaber: I was just starting to look at that. so far I am suspecting something with database access (perhaps improper transaction context manager nesting or something of that nature). I began to look through the bottom patch and I'm not sure about the location of the minimum service version check and trait addition, my inclination is it shouldn't be in the request spec object there,
15:08:15 sean-k-mooney jgilaber: you removed resting the cach
15:08:28 sean-k-mooney in https://review.opendev.org/c/openstack/nova/+/994299/10..13/nova/tests/functional/integrated_helpers.py
15:08:37 melwitt and there is a possibility that moving that part might change whatever is going wrong. BUT this is just my preliminary thoughts and I need to continue to look at it

Earlier   Later