Bug 1025074 - Horizon displays floating IPs to allocate from unreachable external networks of other tenants.
Horizon displays floating IPs to allocate from unreachable external networks ...
Product: Red Hat OpenStack
Classification: Red Hat
Component: python-django-horizon (Show other bugs)
x86_64 Linux
unspecified Severity medium
: ---
: 6.0 (Juno)
Assigned To: Julie Pichon
Ami Jeain
: Triaged
Depends On:
  Show dependency treegraph
Reported: 2013-10-30 19:51 EDT by Nir Magnezi
Modified: 2015-02-15 17:02 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2014-09-16 03:56:41 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Network Topology Screenshot (76.08 KB, image/png)
2013-10-30 19:56 EDT, Nir Magnezi
no flags Details

External Trackers
Tracker ID Priority Status Summary Last Updated
Launchpad 1246525 None None None Never

  None (edit)
Description Nir Magnezi 2013-10-30 19:51:54 EDT
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 2013-10-24.5

How reproducible:

Steps to Reproduce:
1. Have two tenants (admin tenant, test tenant)
2. Network for admin tenant:
   - Create network named: internal with the subnet
   - Create network named: external with the subnet check External Network in Admin tab for this network.
   - Create Router named: Router1, Set gateway network: external
3. Network for admin tenant:
   - Create network named: internal2 with the subnet
   - Create network named: external2 with the subnet 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

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

Additional Info:
I've yet to test if this reproduces in Havana.
Comment 1 Nir Magnezi 2013-10-30 19:56:17 EDT
Created attachment 817657 [details]
Network Topology Screenshot

This is how the network topology should look like.
Comment 3 Julie Pichon 2013-11-14 13:23:00 EST
Discussion on-going upstream as to whether this should be done in Horizon or Neutron, as Horizon would end up duplicating a lot of the logic that should already be present in Neutron.
Comment 4 Julie Pichon 2013-11-14 13:27:49 EST
Note: although the external network appears to belong to another tenant, external networks can't be private in the current Neutron implementation.

"Currently the concept of 'external' network is somewhat similar to the concept of a 'shared' network. However, while every tenant can operate on a shared network, performing operations such as creating port, the set of operations a tenant can perform on an external network is more limited, as it's currently restrained to setting external gateways on routers and creating floating IPs.

Nevertheless, the concept of 'external' implies some forms of sharing, and this has some bearing on the topologies that can be achieved. For instance it is not possible at the moment have an external network which is reserved to a specific tenant. That external network will always show up in queries performed by other tenants too."

From https://wiki.openstack.org/wiki/Neutron/sharing-model-for-external-networks

These external networks can be used by another tenant if they make the right connection to their internal networks using a router.

The problem statement that I agree with is that you're presented with a list of floating IPs pools that you may not have access to because you haven't created the right topology to be able to use them yet, which is confusing.
Comment 5 Matthias Runge 2014-09-16 03:56:41 EDT
From upstream bug report:
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*.

Upstream (neutron and Horizon) both closed this as invalid bug.

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