Bug 1295202

Summary:	Floating IP status is blank after associating it with an instance
Product:	Red Hat OpenStack	Reporter:	Itzik Brown <itbrown>
Component:	openstack-neutron	Assignee:	Ihar Hrachyshka <ihrachys>
Status:	CLOSED DUPLICATE	QA Contact:	Ofer Blaut <oblaut>
Severity:	urgent	Docs Contact:
Priority:	high
Version:	7.0 (Kilo)	CC:	abregman, amuller, chrisw, itbrown, jschluet, lpeer, nyechiel, yeylon
Target Milestone:	async	Keywords:	AutomationBlocker, Regression, ZStream
Target Release:	7.0 (Kilo)
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2016-01-13 15:49:51 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Itzik Brown 2016-01-03 14:02:00 UTC

Description of problem:
After creating a Floating IP and associating it with an instance the status of the FIP is blank with cause tempest to fail on several tests.

Version-Release number of selected component (if applicable):
OSPD 7.2
openstack-neutron-2015.1.2-5.el7ost.noarch
openstack-neutron-openvswitch-2015.1.2-5.el7ost.noarch
openstack-neutron-common-2015.1.2-5.el7ost.noarch
python-neutronclient-2.4.0-2.el7ost.noarch
python-neutron-2015.1.2-5.el7ost.noarch
openstack-neutron-ml2-2015.1.2-5.el7ost.noarch


How reproducible:


Steps to Reproduce:
1. Create a floating IP
2. Associate the instance with the floating IP 
   # nova floating-ip-associate <instance> <FIP>
3. Verify the status of the FIP
   # neutron floatingip-show

Actual results:


Expected results:


Additional info:
Using packstack with the following packages - no problem:
openstack-neutron-fwaas-2015.1.2-1.el7ost.noarch
openstack-neutron-openvswitch-2015.1.2-3.el7ost.noarch
openstack-neutron-common-2015.1.2-3.el7ost.noarch
python-neutron-fwaas-2015.1.2-1.el7ost.noarch
python-neutronclient-2.4.0-2.el7ost.noarch
python-neutron-2015.1.2-3.el7ost.noarch
openstack-neutron-2015.1.2-3.el7ost.noarch
openstack-neutron-ml2-2015.1.2-3.el7ost.noarch

Comment 2 Nir Yechiel 2016-01-04 09:05:24 UTC

A few clarification following a chat with Itzik on irc:

*Floating IPs are working as expected. The issue is with the 'status' output which shows blank instead of 'ACTIVE'.

*This seems to be specific to OSP director based deployments.

Comment 4 Itzik Brown 2016-01-06 10:03:16 UTC

The issue occurred using OSPD7

Comment 6 Jon Schlueter 2016-01-07 16:25:23 UTC

(In reply to Itzik Brown from comment #0)
> Steps to Reproduce:
> 1. Create a floating IP
> 2. Associate the instance with the floating IP 
>    # nova floating-ip-associate <instance> <FIP>
> 3. Verify the status of the FIP
>    # neutron floatingip-show


did you intentionally use both nova and neutron floating ip support?

Comment 8 Itzik Brown 2016-01-10 06:49:09 UTC

(In reply to Jon Schlueter from comment #6)
> (In reply to Itzik Brown from comment #0)
> > Steps to Reproduce:
> > 1. Create a floating IP
> > 2. Associate the instance with the floating IP 
> >    # nova floating-ip-associate <instance> <FIP>
> > 3. Verify the status of the FIP
> >    # neutron floatingip-show
> 
> 
> did you intentionally use both nova and neutron floating ip support?

There are two way to associate a floating IP - to a port using Neutron or to an instance using Nova. It's convenient to use Nova.

Comment 9 Assaf Muller 2016-01-13 15:45:19 UTC

*** Bug 1296169 has been marked as a duplicate of this bug. ***

Comment 10 Assaf Muller 2016-01-13 15:49:32 UTC

The problem is that with HA routers we don't get the floating IP status. This is why Arie couldn't reproduce this on Packstack based jobs (No HA). It's always been like this, ever since we introduced HA routers in Juno, because I commented out this bit of code back then:
https://github.com/openstack/neutron/blob/master/neutron/agent/l3/ha_router.py#L257

Setting as a duplicate of https://bugzilla.redhat.com/show_bug.cgi?id=1284739.

Comment 11 Assaf Muller 2016-01-13 15:49:51 UTC


*** This bug has been marked as a duplicate of bug 1284739 ***