Reviewed: https://review.opendev.org/c/openstack/neutron/+/815255 Committed: https://opendev.org/openstack/neutron/commit/11d166be683d36ba51e3f85ddea45cb0a1fcf8db Submitter: "Zuul (22348)" Branch: master
commit 11d166be683d36ba51e3f85ddea45cb0a1fcf8db Author: Slawek Kaplonski <[email protected]> Date: Mon Oct 25 10:59:24 2021 +0200 Don't setup bridge controller if it is already set Setting new controller for bridge every time when neutron-ovs-agent is restarted or is doing full-sync may cause some short data plane connectivity loss and is not needed if same controller is already configured for the bridge. With this patch neutron-ovs-agent will first check if controller is configured for the bridge and if it's the same as what should be configured, it will skip setting it up. With this patch also protocols added to the bridge will be first checked if they aren't already there and only missing ones will be added if necessary. Setting of the connectivity mode and inactivity probe is always performed as this don't cause connectivity issues and is cheap so we can always ensure that those parameters are configured properly. Closes-Bug: #1948642 Change-Id: Idfa763df8c60d8ae46cd6351d1b6dc7d950b4c67 ** Changed in: neutron Status: In Progress => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1948642 Title: Configuration of the ovs controller by neutron-ovs-agent isn't idempotent Status in neutron: Fix Released Bug description: When neutron-ovs-agent is restarted, or doing full sync e.g. after recovery of the connectivity to rabbitmq, it is setting controller for bridges in the openvswitch. That operation isn't idempotent, and even if controller was already created, it will create new one. That, in some cases can lead to short (1-2 seconds) traffic loss in the dataplane. We observed that by doing UDP traffic test between 2 VMs: - server A run: sudo iperf3 -s -p 5000 -i 1 - server B run: iperf3 -c 192.168.155.143 -p 5000 -u --length 1400 -b 1M -i 1 -t 3001 When neutron-ovs-agent on the node where server B runs is restarted, packet loss can be observed in iperf, like: [ 5] 44.00-45.00 sec 122 KBytes 997 Kbits/sec 0.028 ms 0/89 (0%) iperf3: OUT OF ORDER - incoming packet = 4047 and received packet = 4048 AND SP = 5 iperf3: OUT OF ORDER - incoming packet = 4046 and received packet = 4049 AND SP = 5 iperf3: OUT OF ORDER - incoming packet = 4051 and received packet = 4053 AND SP = 5 iperf3: OUT OF ORDER - incoming packet = 4052 and received packet = 4054 AND SP = 5 [ 5] 45.00-46.00 sec 123 KBytes 1.01 Mbits/sec 0.021 ms 4/90 (4.4%) [ 5] 46.00-47.00 sec 122 KBytes 997 Kbits/sec 0.028 ms 0/89 (0%) iperf3: OUT OF ORDER - incoming packet = 4218 and received packet = 4219 AND SP = 5 iperf3: OUT OF ORDER - incoming packet = 4220 and received packet = 4221 AND SP = 5 iperf3: OUT OF ORDER - incoming packet = 4222 and received packet = 4223 AND SP = 5 [ 5] 47.00-48.00 sec 122 KBytes 997 Kbits/sec 0.024 ms 3/89 (3.4%) To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1948642/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : [email protected] Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
