← Back to team overview

yahoo-eng-team team mailing list archive

[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