| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2026-07-29 | |||
| 15:10:02 | sean-k-mooney | that is a neutron bug | |
| 15:10:09 | sean-k-mooney | ti is not allowed to requrie that | |
| 15:10:14 | sean-k-mooney | because it will break dpdk if it does | |
| 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: Add libvirt driver MDEV ARQ support for Cyborg https://review.opendev.org/c/openstack/nova/+/995840 | |
| 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 | |
| 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:18 | opendevreview | Anton Iacobaeus proposed openstack/nova master: libvirt: Generalize memory encryption config https://review.opendev.org/c/openstack/nova/+/998466 | |
| 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 | " | |
| 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 | I can read " | |
| 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 | |