| Summary: | Horizon displays floating IPs to allocate from unreachable external networks of other tenants. | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Red Hat OpenStack | Reporter: | Nir Magnezi <nmagnezi> | ||||
| Component: | python-django-horizon | Assignee: | Julie Pichon <jpichon> | ||||
| Status: | CLOSED NOTABUG | QA Contact: | Ami Jeain <ajeain> | ||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | 3.0 | CC: | aortega, athomas, jpichon, mrunge, yeylon | ||||
| Target Milestone: | --- | Keywords: | Triaged | ||||
| Target Release: | 6.0 (Juno) | ||||||
| Hardware: | x86_64 | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2014-09-16 07:56:41 UTC | Type: | Bug | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Attachments: |
|
||||||
|
Description
Nir Magnezi
2013-10-30 23:51:54 UTC
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. |