I've been able to verify the neutron Epoxy update. Further testing information below.
Version tested: neutron-server 2:26.0.5-0ubuntu0.24.04.1 Ran charmed-openstack-tester, results will be attached (accidentally deleted). No failures due to neutron update, all in unrelated tests. Did individual verification of the following bugs, as I knew their fixes were addressed. 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 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 (on newer clouds: openstack router add gateway foobar ext_net) Verified on ovn-central node that the logical router port had the lower of the two mtus: $ sudo ovn-nbctl list Logical_Router_Port 9bf41218-10ad-4635-99cf-2e594992656b _uuid : 9bf41218-10ad-4635-99cf-2e594992656b dhcp_relay : [] enabled : [] external_ids : {"neutron:is_ext_gw"=True, "neutron:network_name"=neutron-9e8e0666-42aa-431c-a287-5d2e0906f80b, "neutron:revision_number"="5", "neutron:router_name"="5739d37e-d240-4ffc-b81e-6b96335f2dce", "neutron:subnet_ids"="1415a905-7d5b-42bf-938d-e311330c0fbf"} gateway_chassis : [11f17ada-e082-4952-934f-21e0ec425e85, 212cdd51-763a-4d5c-92db-679d6ac44baf, 72c9c344-bf65-47f3-a91e-ac5b8e6eb537] ha_chassis_group : [] ipv6_prefix : [] ipv6_ra_configs : {} mac : "fa:16:3e:b1:bf:ac" name : lrp-ab8c6a58-f182-4801-abcc-0b9148f37486 networks : ["10.159.5.219/25"] options : {gateway_mtu="1400", reside-on-redirect-chassis="true"} peer : [] status : {hosting-chassis=juju-716782-zaza-659c195dee9d-29} "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 Then pinged the floating IP of the other VM, which has a smaller mtu: $ ping -s 1400 10.159.5.213 PING 10.159.5.213 (10.159.5.213) 1400(1428) bytes of data. From 10.159.5.219 icmp_seq=1 Frag needed and DF set (mtu = 1400) 1408 bytes from 10.159.5.213: icmp_seq=3 ttl=62 time=11.5 ms 1408 bytes from 10.159.5.213: icmp_seq=4 ttl=62 time=0.852 ms Frag needed message indicates fix worked correctly. Ping also succeeded. ** Tags removed: verification-epoxy-needed ** Tags added: verification-epoxy-done -- 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
