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

[Nir Magnezi]

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.

[Nir Magnezi (nmagnezi)]

This is how the network topology should look like.

[Akihiro Motoki (amotoki)]

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.

[Eugene Nikanorov (enikanorov)]

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.

[Akihiro Motoki (amotoki)]

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?

[Julie Pichon (jpichon)]

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?

[Akihiro Motoki (amotoki)]

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.

[OpenStack Infra (hudson-openstack)]

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

[Akihiro Motoki (amotoki)]

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

[Akihiro Motoki (amotoki)]

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.

[Akihiro Motoki (amotoki)]

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.

[Launchpad Janitor (janitor)]

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

[Andreas Scheuring (andreas-scheuring)]

Setting to invalid along the comment of Akihiro.