yahoo-eng-team team mailing list archive

[OpenStack Infra <1948642@xxxxxxxxxxxxxxxxxx>]

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 <skaplons@xxxxxxxxxx>
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