Horizon displays floating IPs to allocate from unreachable external networks of other tenants.

Bug #1246525 reported by Nir Magnezi
28
This bug affects 4 people
Affects Status Importance Assigned to Milestone
OpenStack Dashboard (Horizon)
Expired
Undecided
Unassigned
neutron
Invalid
Medium
Eugene Nikanorov

Bug Description

Description of problem:
=======================
Horizon displays floating IPs to allocate from unreachable external networks of other tenants.
Those pools are not reachable and cannot be used by a non related tenant.

Version-Release number of selected component (if applicable):
=============================================================
Grizzly, python-django-horizon-2013.1.4-1.el6ost.noarch

How reproducible:
=================
Always.

Steps to Reproduce:
===================
1. Have two tenants (admin tenant, test tenant)
2. Network for admin tenant:
   - Create network named: internal with the subnet 192.168.1.0/24
   - Create network named: external with the subnet 10.10.10.0/24 check External Network in Admin tab for this network.
   - Create Router named: Router1, Set gateway network: external
3. Network for demo tenant:
   - Create network named: internal2 with the subnet 192.168.2.0/24
   - Create network named: external2 with the subnet 11.11.11.0/24 check External Network in Admin tab for this network.
   - Create Router named: Router2, Set gateway network: external2
4. Launch an instance in admin tenant, attach the 'internal' network.
5. Associate Floating IP to that instance.
5. Click + and select the pool of the other tenant: external2.
6. Click Associate

Actual results:
===============
The IP address (11.11.11.x) suggested belongs to the other tenant pool: external2, which shouldn't be accessible.
Association fails with the following error:

Error: External network d1e2a98f-0ee6-4192-bdd4-eb759456f059 is not reachable from subnet 7e58ab9f-bac4-4544-af64-896c247542bd. Therefore, cannot associate Port 60550899-a94a-44e2-a231-fe344f1d1838 with a Floating IP.

Error: Unable to associate IP address 11.11.11.3.

Expected results:
=================
Only IPs allocated to the current tenant should be listed.

Additional Info:
================
I've yet to test if this reproduces in Havana.

Revision history for this message
Nir Magnezi (nmagnezi) wrote :

This is how the network topology should look like.

Revision history for this message
Akihiro Motoki (amotoki) wrote :

I am not sure it should be fixed in Horizon or Neutron.

IMO Neutron should provide a list of external networks available for a given port. Horizon focuses on UI related processing and most complicated logics depend on back end projects. Horizon can implement the same logic as Neutron does when it is requested to associate an floating IP to a port, but it does not follow DRY policy.

Akihiro Motoki (amotoki)
tags: added: neutron
Changed in neutron:
status: New → Confirmed
importance: Undecided → Medium
tags: added: horizon
description: updated
Revision history for this message
Eugene Nikanorov (enikanorov) wrote :

Akihiro, Mark, to me it seems like a Horizon issue.
External networks are visible to any tenant per policy.json ("get_network": "rule:admin_or_owner or rule:shared or rule:external")
So Horizon, fetching external networks on behalf of the tenant, receives both external networks.
It could be more intelligent and check, if port is on subnet that is connected to external network and offer only that external network.

I don't see an issue with Neutron here.

Changed in neutron:
assignee: nobody → Eugene Nikanorov (enikanorov)
status: Confirmed → Incomplete
Revision history for this message
Akihiro Motoki (amotoki) wrote :

I think it is a topic who should provides a reachability check.

Of course, Horizon can implement more intelligent check if a port on subnet is reachable to external network by mirroring the logic of Neutron. However I have the following concerns on this approach:

* Neutron already has a reachability check (from external network to a given port). Should Horizon implement a check which is completely duplicated to Neutron one? it is not DRY.

* If Neutron enhances a reachability check, can Horizon catch up with it? At now a port directly connected to an external router can be associated with a floating IP in Neutron, so Horizon can copy the logic. However, this limitation can be relaxed. In theory a port can be associated with a floating IP if a port is reachable from an external router even via internal routers. If so, it is hard Horizon knows a full network topology and check network reachability.

I understand it is not a small topic and it may be beyond a bug.

There was a discussion about network topology management on the ML and we agree it is a part of Heat rather than Neutron, but I think reachability check is a part of Neutron.

For a transient solution, we can copy the logic of Neutron to Horizon for better UX.

Thought?

Changed in horizon:
status: New → Confirmed
importance: Undecided → Medium
Revision history for this message
Julie Pichon (jpichon) wrote :

Hi Eugene, Akihiro, thank you for your comments!

Akihiro's comment makes a lot of sense to me, if Neutron already has the reachability information it would be great to surface it in an API, rather than have Horizon try to reproduce the same logic, likely using multiple API calls.

Akihiro, you also suggested as a temporary solution copying the Neutron logic, would you have a link to the code handy so we can get a better feel for the work involved?

Revision history for this message
Akihiro Motoki (amotoki) wrote :

The neutron logic to check the reachability from floating IP to the specified port is here:
http://git.openstack.org/cgit/openstack/neutron/tree/neutron/db/l3_db.py#n574
The error message in the bug description comes from l3.ExternalGatewayForFloatingIPNotFound.

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to horizon (master)

Fix proposed to branch: master
Review: https://review.openstack.org/116564

Changed in horizon:
assignee: nobody → Akihiro Motoki (amotoki)
status: Confirmed → In Progress
Revision history for this message
Akihiro Motoki (amotoki) wrote :

I added the bug number of this bug in the commit message by mistake.
Reset the status to Confirmed.

Changed in horizon:
assignee: Akihiro Motoki (amotoki) → nobody
Akihiro Motoki (amotoki)
Changed in horizon:
assignee: nobody → Akihiro Motoki (amotoki)
Revision history for this message
Akihiro Motoki (amotoki) wrote :

After further investigation, I notice I misunderstood the original bug report.

The original bug report says that floating IPs from unreachable external network are displayed.
This only happens when there are multiple external network.

If a tenant has only one router connected to an external network,
we can know the external network by checking tenant router gateway port.
It can be done.

More complicated case is where a tenant has mulitple external network.
there are two routers where each router is attached to different external network each other.
To handle this, we need to have another drop-down menu to specify which external network is interested.
The first case is very limited case of the second case and if we handle this bug the second case should be considered.

Above two cases happen only when there are multiple external networks,
and multiple external networks is not a common use case even though it can.
Thus I would like to lower the priority to Low.

Though it is not a scope of this bug report, I think more important topic from UX perspective is to limit Floating IP "target" (instance or VM) to reachable ones from external network. It can easily happens when an instance connects to multiple internal networks and the one network is connected to a router attached to an external network and the other network is isolated. It looks more important to be addressed.

Changed in horizon:
importance: Medium → Low
assignee: Akihiro Motoki (amotoki) → nobody
status: In Progress → Confirmed
Revision history for this message
Akihiro Motoki (amotoki) wrote :

I have a time to consider this bug report.

As my conclusion, the bug itself is invalid based on the current description.
In Neutron an external network is not coupled with a specific tenant,
so it is an expected behavior that admin tenant can see "external2" created
by demo tenant and the demo tenant can see "external1" created by admin tenant.
In general, assigning an IP address pool for an external network requires operator-level privileges,
so an external network created by a tenant doesn't make sense.

I don't see any problem in Horizon side and it is almost "Invalid". I would like to see more input from the reporter, so I will mark "Incomplete" in Horizon bug.

As Neutron side, it is already marked as Incomplete and I agree with it.

If this behavior has a problem, it should be discussed as a blueprint of *Neutron*.
We can discuss it in dev ML too.

Changed in horizon:
status: Confirmed → Incomplete
importance: Low → Undecided
Revision history for this message
Launchpad Janitor (janitor) wrote :

[Expired for OpenStack Dashboard (Horizon) because there has been no activity for 60 days.]

Changed in horizon:
status: Incomplete → Expired
Revision history for this message
Andreas Scheuring (andreas-scheuring) wrote :

Setting to invalid along the comment of Akihiro.

Changed in neutron:
status: Incomplete → Invalid
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

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