yahoo-eng-team team mailing list archive

[Brian Haley <1760894@xxxxxxxxxxxxxxxxxx>]

*** This bug is a duplicate of bug 1745468 ***
    https://bugs.launchpad.net/bugs/1745468

We actually just fixed the conntrack issue in master and it's being
backported to stable/queens.  I'll link that bug and close this as a
duplicate.

** This bug has been marked a duplicate of bug 1745468
   Conntrack entry removal can take a long time on large deployments

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1760894

Title:
  very long rpc_loop in neutron openvswitch agent

Status in neutron:
  New

Bug description:
  release: Pike

  ML2 with DVR, L3_HA and L2 population

  When I removed 100 VMs and then spawned new 100 VMs, a dozen of new
  VMs ended in ERROR state because Nova gave up waiting for a "VIF
  plugged in" event from Neutron.

  I figured out that just before spawning new 100 VMs, in neutron
  openvswitch agent the rpc_loop started new iteration to remove a dozen
  ports which were used by old (just removed) VMs.

  The rpc_loop iteration took 465 seconds (almost 8 minutes) and during
  this time, Nova timed out waiting 300 seconds for "VIF plugged in"
  event during spawning new VMs.

  Looks like the most of the time was spend running hundreds of
  conntrack entries deleting commands.

  You will find the rpc_loop DEBUG log in the attachment.

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