yahoo-eng-team team mailing list archive

[Launchpad Bug Tracker <1853613@xxxxxxxxxxxxxxxxxx>]

This bug was fixed in the package neutron - 2:12.1.1-0ubuntu4

---------------
neutron (2:12.1.1-0ubuntu4) bionic; urgency=medium

  * Fix interrupt of VLAN traffic on reboot of neutron-ovs-agent:
  - d/p/0001-ovs-agent-signal-to-plugin-if-tunnel-refresh-needed.patch (LP: #1853613)
  - d/p/0002-Do-not-block-connection-between-br-int-and-br-phys-o.patch (LP: #1869808)
  - d/p/0003-Ensure-that-stale-flows-are-cleaned-from-phys_bridge.patch (LP: #1864822)
  - d/p/0004-DVR-Reconfigure-re-created-physical-bridges-for-dvr-.patch (LP: #1864822)
  - d/p/0005-Ensure-drop-flows-on-br-int-at-agent-startup-for-DVR.patch (LP: #1887148)
  - d/p/0006-Don-t-check-if-any-bridges-were-recrected-when-OVS-w.patch (LP: #1864822)
  - d/p/0007-Not-remove-the-running-router-when-MQ-is-unreachable.patch (LP: #1871850)

 -- Edward Hope-Morley <edward.hope-morley@xxxxxxxxxxxxx>  Mon, 22 Feb
2021 16:55:40 +0000

** Changed in: neutron (Ubuntu Bionic)
       Status: Fix Committed => 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/1853613

Title:
  VMs don't get ip from dhcp after compute restart

Status in neutron:
  Fix Released
Status in neutron package in Ubuntu:
  Incomplete
Status in neutron source package in Bionic:
  Fix Released

Bug description:
  (For SRU template, please see bug 1869808, as the SRU info there
  applies to this bug also)

  Env: pike + ovs + vxlan + l2pop + iptables_hybrid.
  Dhcp agent on differnt node than compute.

  Steps:
  1. Boot 4 or more vms to same compute and same vxlan net.
  2. Wait until they are fully running and reboot compute node.
  3. After boot the vms are in status SHUTOFF. Start the vms.

  Vms don't get an ip address from neutron dhcp. The flood to tunnels
  flow (br-tun table 22) for the network is missing, so broadcasts like
  dhcp requests don't get on a tunnel to the node with dhcp agent.
  Neutron server did not send the flooding entry to the agent. It only
  does that for the first or second active port, or if the agent is
  restarted.

  After the compute boots, neutron-ovs-cleanup runs first and deletes
  the qvo ports from br-int [4]. Then the ovs-agent starts and nova-
  compute after it. Nova-compute destroys the domains and moves the vms
  to SHUTOFF status. It also (for some reason) recreates the qbr linux
  bridges and qvb/qvo veths connected to br-int. So neutron continues to
  see the ports as ACTIVE even though the vms are SHUTOFF, and
  agent_active_ports [1] never drops below 3. Also nova-compute might
  start a short time after the ovs-agent and the new ports are not
  detected in first iteration of the ovs agent loop, so agent_restarted
  will be false here [2].

  Before [3] agent_restarted was true if the agent was running for less
  than agent_boot_time (default 180 sec) and the problem did not show.

  It does not happen if neutron-ovs-cleanup is disabled. Then the ovs
  agent first treats them as skipped_devices and they get status DOWN.

  [1] https://github.com/openstack/neutron/blob/21a52f7ae597f7992f32ff41cedff0c31e35c762/neutron/plugins/ml2/drivers/l2pop/mech_driver.py#L306
  [2] https://github.com/openstack/neutron/blob/21a52f7ae597f7992f32ff41cedff0c31e35c762/neutron/plugins/ml2/drivers/l2pop/mech_driver.py#L310
  [3] https://opendev.org/openstack/neutron/commit/62fe7852bbd70a24174853997096c52ee015e269
  [4] https://bugs.launchpad.net/neutron/+bug/1853582

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1853613/+subscriptions