Reviewed: https://review.openstack.org/640797
Committed:
https://git.openstack.org/cgit/openstack/neutron/commit/?id=a5244d6d44d2b66de27dc77efa7830fa657260be
Submitter: Zuul
Branch: master
commit a5244d6d44d2b66de27dc77efa7830fa657260be
Author: LIU Yulong <i...@liuyulong.me>
Date: Mon Mar 4 21:17:20 2019 +0800
More accurate agent restart state transfer
Ovs-agent can be very time-consuming in handling a large number
of ports. At this point, the ovs-agent status report may have
exceeded the set timeout value. Some flows updating operations
will not be triggerred. This results in flows loss during agent
restart, especially for hosts to hosts of vxlan tunnel flow.
This fix will let the ovs-agent explicitly, in the first rpc loop,
indicate that the status is restarted. Then l2pop will be required
to update fdb entries.
Closes-Bug: #1813703
Closes-Bug: #1813714
Closes-Bug: #1813715
Closes-Bug: #1794991
Closes-Bug: #1799178
Change-Id: I8edc2deb509216add1fb21e1893f1c17dda80961
** 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/1813715
Title:
[L2][scale issue] ovs-agent meets unexpected tunnel lost
Status in neutron:
Fix Released
Bug description:
The ovs-agent will lost some tunnels to other nodes, for instance to DHCP
node or L3 node, these lost tunnels can sometimes cause VM failed to boot or
dataplane down.
When subnets or security group ports quantity reaches 2000+, this issue can
be seen in high probability.
This is a subproblem of bug #1813703, for more information, please see the
summary:
https://bugs.launchpad.net/neutron/+bug/1813703
To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1813715/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
