Bug 1254962 - DVR+LbaasV2- VIP(LB) floating ip is in DOWN state
DVR+LbaasV2- VIP(LB) floating ip is in DOWN state
Status: CLOSED WONTFIX
Product: Red Hat OpenStack
Classification: Red Hat
Component: openstack-neutron-lbaas (Show other bugs)
7.0 (Kilo)
Unspecified Unspecified
unspecified Severity unspecified
: ---
: 8.0 (Liberty)
Assigned To: RHOS Maint
yeylon@redhat.com
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-08-19 06:39 EDT by Alexander Stafeyev
Modified: 2016-04-18 02:51 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-08-19 09:53:35 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Alexander Stafeyev 2015-08-19 06:39:56 EDT
Description of problem:
AIO+Compute setup. LbaasV2+DVR
Floating ip is not going ip after associating it to LB vip. 

When we work with dvr the EXTERNAL (gateway IF) is configured on the snat ns (when in non dvr it is on qrouter ns)

"
[root@puma07 ~(keystone_admin)]# ip netns
qlbaas-0e804f06-c5f7-42ce-a2a2-dceab1021f32
snat-c7f6851d-981b-4b07-9584-0803d0240b7f      <-------------------
qrouter-c7f6851d-981b-4b07-9584-0803d0240b7f
qdhcp-e2a6b8e4-40de-47e5-9dcd-e66121c5562b
"
When we associate floating ip to LB vip it searches the external IF in the router NS.

associating floating ip to VM (without LB) work fine. 


Version-Release number of selected component (if applicable):
python-neutron-fwaas-2015.1.0-3.el7ost.noarch
openstack-neutron-common-2015.1.0-12.el7ost.noarch
python-neutronclient-2.4.0-1.el7ost.noarch
openstack-neutron-2015.1.0-12.el7ost.noarch
python-neutron-lbaas-2015.1.0-5.el7ost.noarch
openstack-neutron-ml2-2015.1.0-12.el7ost.noarch
openstack-neutron-openvswitch-2015.1.0-12.el7ost.noarch
openstack-neutron-lbaas-2015.1.0-5.el7ost.noarch
python-neutron-2015.1.0-12.el7ost.noarch
openstack-neutron-fwaas-2015.1.0-3.el7ost.noarch



How reproducible:


Steps to Reproduce:
1.configure DVR setup AIO+compute
2. Enable lbaasV2. create load-balacner. 
3.Create FloatingIP and assign it to the LB vip port. 

Actual results:
Floating IP is down due to DVR configuration ( gateway IF is on snat Ns and not on router NS)

Expected results:
Floating IP should be up

I think we should do 1 of the following: 
1. When lbaas configured, the "external IF/port" should be on qrouter ns even if it is a DVR environmet- this means no snat or fip namespaces. If additional VMs will be created and assigned with another FIPs then we should use the snat and fip namespaces. 

or 

2. We should use lbaas agent exactly as we are using l3 agent in DVR environment




logs :
2015-08-19 12:16:00.330 6391 INFO neutron.wsgi [req-beec6448-208f-4f71-88c8-c8ace78dddef ] 10.35.160.23 - - [19/Aug/2015 12:16:00] "PUT /v2.0/floatingips/8087cafc-595a-486a-8e12-7016793cfa70.json HTTP/1.1" 200 584 0.484856
2015-08-19 12:16:00.833 6300 DEBUG neutron.db.l3_dvr_db [req-74e2674c-f5d2-40b8-9187-415daba4bb1b ] FIP Agent : 00fe9d29-5c78-4d82-b018-669b2d3fe622  _process_floating_ips_dvr /usr/lib/python2.7/site-packages/neutron/db/l3_dvr_db.py:415
2015-08-19 12:16:00.837 6300 DEBUG neutron.db.l3_dvr_db [req-d975570b-f66d-4825-a9dd-f019ed4fa729 ] FIP Agent : 9eb0dae2-90e9-46b5-afab-d4f5c473e74b  _process_floating_ips_dvr /usr/lib/python2.7/site-packages/neutron/db/l3_dvr_db.py:415
2015-08-19 12:16:01.144 6315 DEBUG neutron.agent.l3.router_info [-] No Interface for floating IPs router: c7f6851d-981b-4b07-9584-0803d0240b7f process_floating_ip_addresses /usr/lib/python2.7/site-packages/neutron/agent/l3/router_info.py:229
2015-08-19 12:16:01.144 6315 DEBUG neutron.agent.l3.agent [-] Sending floating ip statuses: {} update_fip_statuses /usr/lib/python2.7/site-packages/neutron/agent/l3/agent.py:340
Comment 3 Assaf Muller 2015-08-19 09:53:35 EDT
The general workflow is to open the bug upstream unless there is something downstream specific like SELinux, installer configuration, packaging etc. The reason for this is that there are a lot more developers upstream than in Red Hat and it's often the case where you open the bug u/s and a random community member will pick it up.
Comment 4 Alexander Stafeyev 2015-08-23 01:42:40 EDT
Opened launchpad bug 
https://bugs.launchpad.net/neutron/+bug/1487823

tnx

Note You need to log in before you can comment on or make changes to this bug.