yahoo-eng-team team mailing list archive
-
yahoo-eng-team team
-
Mailing list archive
-
Message #45889
[Bug 1443421] Re: After VM migration, tunnels not getting removed with L2Pop ON, when using multiple api_workers in controller
Reviewed: https://review.openstack.org/215467
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=c5fa665de3173f3ad82cc3e7624b5968bc52c08d
Submitter: Jenkins
Branch: master
commit c5fa665de3173f3ad82cc3e7624b5968bc52c08d
Author: shihanzhang <shihanzhang@xxxxxxxxxx>
Date: Fri Aug 21 09:51:59 2015 +0800
ML2: update port's status to DOWN if its binding info has changed
This fixes the problem that when two or more ports in a network
are migrated to a host that did not previously have any ports in
the same network, the new host is sometimes not told about the
IP/MAC addresses of all the other ports in the network. In other
words, initial L2population does not work, for the new host.
This is because the l2pop mechanism driver only sends catch-up
information to the host when it thinks it is dealing with the first
active port on that host; and currently, when multiple ports are
migrated to a new host, there is always more than one active port so
the condition above is never triggered.
The fix is for the ML2 plugin to set a port's status to DOWN when
its binding info changes.
This patch also fixes the bug when nova thinks it should not wait
for any events from neutron because all ports are already active.
Closes-bug: #1483601
Closes-bug: #1443421
Closes-Bug: #1522824
Related-Bug: #1450604
Change-Id: I342ad910360b21085316c25df2154854fd1001b2
** 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/1443421
Title:
After VM migration, tunnels not getting removed with L2Pop ON, when
using multiple api_workers in controller
Status in neutron:
Fix Released
Status in openstack-ansible:
Confirmed
Status in openstack-ansible trunk series:
Confirmed
Bug description:
Using multiple api_workers, for "nova live-migration" command,
a) tunnel flows and tunnel ports are always removed from old host
b) and other hosts(sometimes) not getting notification about port delete from old host. So in other hosts, tunnel ports and flood flows(except unicast flow about port) for old host still remain.
Root cause and fix is explained in comments 12 and 13.
According to bug reporter, this bug can also be reproducible like below.
Setup : Neutron server HA (3 nodes).
Hypervisor – ESX with OVsvapp
l2 POP is on Network node and off on Ovsvapp.
Condition:
Make L2 pop on OVs agent, api workers =10 in the controller.
On network node,the VXLAN tunnel is created with ESX2 and the Tunnel
with ESX1 is not removed after migrating VM from ESX1 to ESX2.
Attaching the logs of servers and agent logs.
stack@OSC-NS1:/opt/stack/logs/screen$ sudo ovs-vsctl show
662d03fb-c784-498e-927c-410aa6788455
Bridge br-ex
Port phy-br-ex
Interface phy-br-ex
type: patch
options: {peer=int-br-ex}
Port "eth2"
Interface "eth2"
Port br-ex
Interface br-ex
type: internal
Bridge br-tun
Port patch-int
Interface patch-int
type: patch
options: {peer=patch-tun}
Port "vxlan-6447007a"
Interface "vxlan-6447007a"
type: vxlan
options: {df_default="true", in_key=flow, local_ip="100.71.0.41", out_key=flow, remote_ip="100.71.0.122"} <<<<<<<<<<<< This should have been deleted after MIGRATION.
Port "vxlan-64470082"
Interface "vxlan-64470082"
type: vxlan
options: {df_default="true", in_key=flow, local_ip="100.71.0.41", out_key=flow, remote_ip="100.71.0.130"}
Port br-tun
Interface br-tun
type: internal
Port "vxlan-6447002a"
Interface "vxlan-6447002a"
type: vxlan
options: {df_default="true", in_key=flow, local_ip="100.71.0.41", out_key=flow, remote_ip="100.71.0.42"}
Bridge "br-eth1"
Port "br-eth1"
Interface "br-eth1"
type: internal
Port "phy-br-eth1"
Interface "phy-br-eth1"
type: patch
options: {peer="int-br-eth1"}
Bridge br-int
fail_mode: secure
Port patch-tun
Interface patch-tun
type: patch
options: {peer=patch-int}
Port "int-br-eth1"
Interface "int-br-eth1"
type: patch
options: {peer="phy-br-eth1"}
Port br-int
Interface br-int
type: internal
Port int-br-ex
Interface int-br-ex
type: patch
options: {peer=phy-br-ex}
Port "tap9515e5b3-ec"
tag: 11
Interface "tap9515e5b3-ec"
type: internal
ovs_version: "2.0.2"
To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1443421/+subscriptions
References