yahoo-eng-team team mailing list archive
-
yahoo-eng-team team
-
Mailing list archive
-
Message #30701
[Bug 1425639] Re: A functional floating ip stops working sometimes if another floating ip is created and deleted.
The code structure has changed significantly and haven't heard of any
other citing of this specific issue for a while so marking it as invalid
for now.
** Changed in: neutron
Status: In Progress => Invalid
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1425639
Title:
A functional floating ip stops working sometimes if another floating
ip is created and deleted.
Status in OpenStack Neutron (virtual network service):
Invalid
Bug description:
A test failure was noticed for test_cross_tenant_traffic at [1] .
A floating ip ‘a’ was instantiated on router A .
The floating IP was functional
A floating IP ‘b’ was instantiated on router B after about 30 seconds
Floating IP on router B was functional
Floating IP on router B was deleted
Floating IP on A was not reachable anymore
Root cause appears to be:
Analyzing from the logs it appears Agent gateway port was being created at instantiation of both the floating IPs and deleted on deletion of Floating IP ‘b’.
[2] , [3] , [4]
Expected behavior was to have Agent Gateway port created only once and not deleted on deletion of Floating IP ‘b’.
Creation and deletion of Agent Gateway port is guarded by the is_first and is_last checks on the subscribers set.
The subscribers set is a member of the FipNamespace Class
FipNamespace objects are stored as weakreferences
It appears the weakreference to the FipNamespace object created at
the time of instantiation of floating IP ‘a’ was lost/garbage
collected before instantiation of floating IP ‘b’ and therefore a new
object of class Fipnamespace was instantiated which came along with a
new subscribers set member. This in turn led to passing of the
is_first and is_last checks for router B thus leading to failures.
[1] http://logs.openstack.org/22/153422/8/check/check-tempest-dsvm-
neutron-dvr/3db7309/logs/testr_results.html.gz
[2] http://logs.openstack.org/22/153422/8/check/check-tempest-dsvm-
neutron-dvr/3db7309/logs/screen-q-vpn.txt.gz#_2015-02-24_02_20_16_355
[3] http://logs.openstack.org/22/153422/8/check/check-tempest-dsvm-
neutron-dvr/3db7309/logs/screen-q-vpn.txt.gz#_2015-02-24_02_22_10_735
[4] http://logs.openstack.org/22/153422/8/check/check-tempest-dsvm-
neutron-dvr/3db7309/logs/screen-q-vpn.txt.gz#_2015-02-24_02_21_57_960
To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1425639/+subscriptions
References