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 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 admin 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.
Created attachment 817657 [details] Network Topology Screenshot This is how the network topology should look like.
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.
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.
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.