tenant lists the external network of other tenants

I think this is a possibly undesired effect of the fact that external networks, just like shared networks, can be 'read' by all tenants.

the reason for this is that a tenant should be allowed to set a gateway for his own router on a network he does not own; also he must be allowed to create floating IPs on a network he does not own.

the side effect is that quantum does not provide a way to create an external network which is completely private too.
While this was acceptable for the Folsom model, it is limiting for the Grizzly model, and might end up being unacceptable in Havana.

So I think this bug report is valid, altough its solution won't be very trivial.

Salvatore,
I could not understood the sentence "it is limiting for the Grizzly model". Are there any difference between Folsom model and Grizzly model in L3?

I agree this bug report is valid.

Yeah the difference was that for Folsom we were limited to a single instance of the l3-agent, and hence a single external network.
In that case basically the only possible deployment was to have provider-owned external networks.

With Grizzly you can have multiple external networks, which are probably still provider-owned, but a provider might want to choose how to share them among tenants.

This might be even more delicate with Havana were one might end up having tenant-owned external networks (but honestly I'm not sure whether this is on the roadmap)

Even in folsom, i believe you could have multiple external networks (it
just required multiple l3-agents running on different nodes).

The behavior described in this "bug" is the intended behavior. External
networks are created by an admin user and visible to everyone. I can see a
desire to want to only expose certain external networks to certain tenants,
but that was not the goal of the original design. I can see tracking this
as a change we may want to do in the future, but I don't think we should
track it as a bug, as it required non-trivial discussion around the right
way to expose more flexible control of external networks, which to me
suggests a blueprint.

On Mon, Apr 8, 2013 at 12:49 PM, Salvatore Orlando <
<email address hidden>> wrote:

> Yeah the difference was that for Folsom we were limited to a single
> instance of the l3-agent, and hence a single external network.
> In that case basically the only possible deployment was to have
> provider-owned external networks.
>
> With Grizzly you can have multiple external networks, which are probably
> still provider-owned, but a provider might want to choose how to share
> them among tenants.
>
> This might be even more delicate with Havana were one might end up
> having tenant-owned external networks (but honestly I'm not sure whether
> this is on the roadmap)
>
> --
> You received this bug notification because you are a member of Netstack
> Core Developers, which is subscribed to quantum.
> https://bugs.launchpad.net/bugs/1165002
>
> Title:
> tenant lists the external network of other tenants
>
> Status in OpenStack Quantum (virtual network service):
> Confirmed
>
> Bug description:
> $ quantum net-list
>
> +--------------------------------------+--------+---------------------------------------+
> | id | name | subnets
> |
>
> +--------------------------------------+--------+---------------------------------------+
> | 0b7805ac-f0ae-4bbb-8dd4-75d30d196a61 | pubnet |
> 193dc2ec-9893-423a-a59f-77eca753f197 |
> | d08a06e3-2d42-449c-9579-35c03119d668 | net2 |
> |
>
> +--------------------------------------+--------+---------------------------------------+
>
> Note:
> pubnet is network of other tenant.
> net2 is a shared network of other tenant
>
> gongysh@controlnode:~$ quantum net-show pubnet
> +-----------------+--------------------------------------+
> | Field | Value |
> +-----------------+--------------------------------------+
> | admin_state_up | True |
> | id | 0b7805ac-f0ae-4bbb-8dd4-75d30d196a61 |
> | name | pubnet |
> | router:external | True |
> | shared | False |
> | status | ACTIVE |
> | subnets | 193dc2ec-9893-423a-a59f-77eca753f197 |
> | tenant_id | 3671f46ec35e4bbca6ef92ab7975e463 |
> +-----------------+--------------------------------------+
>
> gongysh@controlnode:~$ quantum port-create pubnet
> ...

I was indeed going to convert it to a blueprint, as it is far from trivial, and might also involve api changes.
I am not able to provide more details at the minute, as I haven't fleshed out yet all of them.

I just assigned it to myself as it make sense to look at it as an API/authZ problem.

I think we should enable other tenants to list the *shared external network.

Replaced it with a blueprint as suggested: https://blueprints.launchpad.net/quantum/+spec/sharing-model-for-external-networks