Mirantis OpenStack

[Backport 1515341] DVR associating a new floatingip on existing network fails after restart of l3 agent

Bug #1556099 reported by Oleg Bondarev
28
This bug affects 4 people
Affects Status Importance Assigned to Milestone
Mirantis OpenStack
Status tracked in 10.0.x
10.0.x
Invalid
High
Unassigned
Mirantis OpenStack 10.0
7.0.x
Fix Released
Critical
Oleg Bondarev
Mirantis OpenStack 7.0-mu-4
8.0.x
Invalid
High
Denis Puchkin
Mirantis OpenStack 8.0-updates
9.x
Invalid
High
Oleg Bondarev
Mirantis OpenStack 9.0

Bug Description

Upstream bug: https://bugs.launchpad.net/neutron/+bug/1515341

If DVR is enabled and an l3-agent is restarted, adding a new vm to an existing network and then associating a floating ip to that vm will fail and set all floating ip statuses on that network to 'ERROR'. In tracking down this issue, it appears that the 'floating_ip_added_dist' method in agent/l3/dvr_local_router.py attempts to invoke 'self.rtr_fip_subnet.get_pair()' without first checking that self.rtr_fip_subnet is not None.

To reproduce this issue:
On a running DVR enabled installation, create a network, subnet, external network and router.
Boot a vm on the network and associate a floating ip to the vm.
Restart the neutron-l3-agent on the compute node hosting the vm.
Boot a second vm on the existing network hosted on the compute node where the neutron-l3-agent has been restarted.
Associate a new floatingip to the second vm.
Observe that the flaotingip is in the ERROR state and that the vm is not pingable via that floatingip.

Revision history for this message
Oleg Bondarev (obondarev) wrote :

Kilo backport: https://review.openstack.org/#/c/251388/ to be backported to MOS

Revision history for this message
Fuel Devops McRobotson (fuel-devops-robot) wrote : Fix proposed to openstack/neutron (openstack-ci/fuel-7.0/2015.1.0)

Fix proposed to branch: openstack-ci/fuel-7.0/2015.1.0
Change author: Oleg Bondarev <email address hidden>
Review: https://review.fuel-infra.org/17984

Changed in mos:
status: Confirmed → In Progress
Eugene Nikanorov (enikanorov)
Changed in mos:
importance: High → Critical
Roman Rufanov (rrufanov)
tags: added: support
Ekaterina Shutova (eshutova)
tags: added: on-automation
Revision history for this message
Ekaterina Shutova (eshutova) wrote :

Test case is automated: https://mirantis.testrail.com/index.php?/cases/view/851852

tags: removed: on-automation
Ekaterina Shutova (eshutova)
tags: added: covered-automated-test
Revision history for this message
Vitaly Sedelnik (vsedelnik) wrote :

Invalid for 9.0 and 10.0 because this issue is fixed in upstream. Targeted to 8.0-mu-2

Changed in mos:
milestone: 8.0-updates → 8.0-mu-2
Dmitry Belyaninov (dbelyaninov)
tags: added: on-verification
Revision history for this message
Fuel Devops McRobotson (fuel-devops-robot) wrote : Fix merged to openstack/neutron (openstack-ci/fuel-7.0/2015.1.0)

Reviewed: https://review.fuel-infra.org/17984
Submitter: Vitaly Sedelnik <email address hidden>
Branch: openstack-ci/fuel-7.0/2015.1.0

Commit: 6d99b0692c8d4d2d844c19b99da2fd241a9c747f
Author: Erik Colnick <email address hidden>
Date: Fri Mar 18 07:17:18 2016

Fix dvr_local_router.floating_ip_added_dist failure after agent restart

If DVR is enabled and an l3-agent is restarted, associating a floatingip
to an existing vm on the compute node where the l3-agent was restarted
will fail. This commit fixes the floating_ip_added_dist method in
dvr_local_router.py so that self.rtr_fip_subnet will be created if
it is 'None' prior to the attempt to call the get_name() method on
it.

Closes-Bug: #1556099
Closes-Bug: #1515341
(cherry picked from commit da3de52c507544c84463a037acac3b2b24a37fe0)

Change-Id: I860ee3522275f62f393e66853e53ef387598983d

Revision history for this message
Dmitry Belyaninov (dbelyaninov) wrote :

Tested on 7.0 MU4
Described scenario works fine
Both floating IPs are in Active state and VMs are available

tags: removed: on-verification
Revision history for this message
Denis Puchkin (dpuchkin) wrote :

invalid for 8.0-mu2, because neutron code already contain this fix

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.