I've also been able to verify the neutron Epoxy update. Further testing information below.
Version tested: neutron-server 2:24.2.2-0ubuntu0.24.04.1 Ran charmed-openstack-tester, results are attached. No failures due to neutron update, all in unrelated tests. Did individual verification of the following bugs: 1) https://bugs.launchpad.net/neutron/+bug/2069442 Issue was traceback seen intermittently when deleting VMs Verified changed code was present and neutron traceback didn't happen over multiple attempts creating/deleting instances in a loop, for example: while true; do openstack server create... openstack server delete... done Additionally, verified in the neutron server logs that this case was caught and logged as expected: sudo tail -f neutron-server.log | grep "Standard attribute was not found for port" 2026-10-14 19:18:04.057 2652292 DEBUG neutron.plugins.ml2.drivers.ovn.mech_driver.mech_driver [None req-71cd3d88-6a1d-4677-995d-1700a5996e38 - - - - - -] Standard attribute was not found for port ad58252a-380f-4a0d-8273-4ac326130c04. It was possibly deleted concurrently. _ovn_update_port /usr/lib/python3/dist-packages/neutron/plugins/ml2/drivers/ovn/mech_driver/mech_driver.py:882 2026-10-14 19:25:28.489 2652293 DEBUG neutron.plugins.ml2.drivers.ovn.mech_driver.mech_driver [None req-dbaf8534-476f-4446-9ce3-8e4d4a31334a - - - - - -] Standard attribute was not found for port cf63347e-42c0-41d5-8071-72144cbc8b57. It was possibly deleted concurrently. _ovn_update_port /usr/lib/python3/dist-packages/neutron/plugins/ml2/drivers/ovn/mech_driver/mech_driver.py:882 2) https://bugs.launchpad.net/neutron/+bug/2116087 Verified changed code was present and neutron port binding operates as expected. 3) https://bugs.launchpad.net/neutron/+bug/2032817 Issue was that mixed network MTU values would lead to traffic being dropped transiting the router/gateway node. First verified "need to frag" was set to true on neutron-api unit: plugins/ml2/ml2_conf.ini:ovn_emit_need_to_frag = True Then created some test resources from the undercloud: $ openstack network create foo $ openstack subnet create --network foo --subnet-range 10.2.0.0/24 foo $ openstack network create --mtu 1400 bar $ openstack subnet create --network bar --subnet-range 10.3.0.0/24 bar $ openstack router create foobar $ openstack router add subnet foobar foo $ openstack router add subnet foobar bar $ openstack router set --external-gateway ext_net foobar Verified on ovn-central node that the logical router port had the lower of the two mtus: $ sudo ovn-nbctl --no-leader-only list Logical_Router_Port 89d21be3-18d1-4438-b21c-17f5eb575c5d _uuid : 89d21be3-18d1-4438-b21c-17f5eb575c5d enabled : [] external_ids : {"neutron:is_ext_gw"=True, "neutron:network_name"=neutron-e5692eef-4696-4601-a403-513d876b45f2, "neutron:revision_number"="4", "neutron:router_name"="48ca6ea1-2deb-4761-98c3-937c5178c07e", "neutron:subnet_ids"="4cb18449-f1d2-4138-aee3-c47766c5c82b"} gateway_chassis : [359183a5-1ffa-4496-9b12-26925ec85410, 7635d4bc-64fd-4f11-8302-a6f222269bbe, e2e32496-1db5-461f-8a3e-04535bfa8d13] ha_chassis_group : [] ipv6_prefix : [] ipv6_ra_configs : {} mac : "fa:16:3e:f4:1b:16" name : lrp-1aa261a4-1bf7-4694-96f8-172695c45870 networks : ["10.159.0.100/25"] options : {gateway_mtu="1400", reside-on-redirect-chassis="true"} peer : [] status : {hosting-chassis=juju-efeb59-zaza-3f5c5de4ec33-27} "1400" here is correct, would have been 1442 without the fix. Launched two instances, one on each network, so one will have a larger mtu than the other. $ ./tools/instance_launch.sh 1 --image jammy --name foovm --network foo $ ./tools/instance_launch.sh 1 --image jammy --name barvm --network bar $ ./tools/float_all.sh Logged-into the VM with the larger mtu (foovm). Verified mtu settings: $ ip a s dev ens2 2: ens2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1442 qdisc fq_codel state UP group default qlen 1000 link/ether fa:16:3e:4d:38:ef brd ff:ff:ff:ff:ff:ff altname enp0s2 inet 10.2.0.17/24 metric 100 brd 10.2.0.255 scope global dynamic ens2 valid_lft 43074sec preferred_lft 43074sec inet6 fe80::f816:3eff:fe4d:38ef/64 scope link valid_lft forever preferred_lft forever Then pinged the floating IP of the other VM, which has a smaller mtu: $ ping -s 1400 10.159.0.126 PING 10.159.0.126 (10.159.0.126) 1400(1428) bytes of data. From 10.2.0.1 icmp_seq=1 Frag needed and DF set (mtu = 1400) 1408 bytes from 10.159.0.126: icmp_seq=2 ttl=62 time=4.53 ms 1408 bytes from 10.159.0.126: icmp_seq=3 ttl=62 time=2.41 ms 1408 bytes from 10.159.0.126: icmp_seq=4 ttl=62 time=1.60 ms Frag needed message indicates fix worked correctly. Ping also succeeded. ** Attachment added: "openstack-tests-2.txt" https://bugs.launchpad.net/ubuntu/resolute/+source/neutron/+bug/2148509/+attachment/6013056/+files/openstack-tests-2.txt ** Tags removed: verification-needed-noble ** Tags added: verification-done-noble -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2148509 Title: [SRU] Neutron stable point releases To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-archive/+bug/2148509/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
