Neutron/sharing-model-for-external-networks

External = True independent from Shared

Impossible to assume external => shared

Sharing model for external networks

Current logic

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 a shared 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.

Goal

The goal of this blueprint is to find a solution for limiting the visibility scope of an external network while preserving backward compatibility. If a reasonable solution which preserves backward compatibility can't be found this blueprint should be deferred to the next release.

Decoupling 'shared' from 'external': this won't work

Apparently the easiest solution is to decouple the concept of 'external' from the concept of sharing. External will qualify the network in topological terms, whereas 'shared' will qualify it in terms of access. In this way, POST shared=True 1) shared = True, external=False

PUT external=True 2) shared=True, external=TRue

PUT external=False 3) shared=False, external=False

3 != 1 and this is wrong

Also, checking on get whether tenant_id of the network is admin or not is terribly expensive even if we perform this check only on external networks. The check will require a round trip to Keystone.

EXTERNAL, BUT SPECIFIC TO TENANT get_networks won't return it

1) EXTRA FLAG, not exposed via API. Might work but it's ugly - unless we find a good reason for it and we expose it through the API (---private?) 1.A) implicitly set db column for privatise the network if it's external and the tenant_id selected != from context.tenant_id (still has weaknesses) 1.B) Introduce a concept of private network. By default each network is private. A network can't be private and shared at the same time. A network however can be private and external at the same time. 2) TENANT_ID=None for external networks which should be shared as well. Implications due to resources without tenant_id. Resource without owners might be troublesome. 3) there is no option 3 so far