OS::Neutron::Router needs property 'tenant_id'

[Yi Liu]

I tried to create a router through heat template, but failed. And I got the error:
2013-10-31 16:27:08.741 20029 TRACE heat.engine.resource NeutronClientException: Running without keystone AuthN requires that tenant_id is specified

However, I found OS::Neutron::Router doesn't have a 'tenant_id' property.

I'm not sure this is a bug or not? Maybe it is only because I'm missing some configuration for Neutron? I'm now still working on it...

Anyhow, I think it is better for OS::Neutron::Router to have a 'tenant_id' property.

[Steve Baker (steve-stevebaker)]

Resources created by heat should always be scoped to the tenant that created the resource.

So rather than adding a tenant_id property, the create_router call should include the tenant_id from the request context.

[Steve Baker (steve-stevebaker)]

Hmm, OS::Neutron::Net has a tenant_id attribute for admin created nets, maybe it is appropriate to add tenant_id to Router

[Angus Salkeld (asalkeld)]

*project_id*

[Steve Baker (steve-stevebaker)]

Maybe tenant_id initially, then later deprecate all tenant_id properties when project_id properties are added.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/60607

[Steven Hardy (shardy)]

As noted in https://review.openstack.org/#/c/60607/ I'm worried we're doing the wrong thing here.

See keysone bug #968696 - there is no such thing as a global admin - all admin role assignment should be scoped per project - so we should not be perpetuating that bug by allowing resources to be leaked between projects/tenants like this.

I'm not sure why this capability exists in neutron - we probably need further discussion of the use-case, but we should not be enabling users to routinely defeat the tenant scoping stated in the request context (derived from the scope of the keystone token, so that is what we should enforce!)

This is basically going in the exact opposite direction of where I think we should be headed, ref the request-scoping-policy bp.

[Steve Baker (steve-stevebaker)]

I'll kick to i-3 for now, but if there is an appropriate way forward which is not this then feel free to mark this as invalid.

[Song Li (lisong-cruise)]

Hi Steve, I am agree with your comment #5

I think project admin should be limited into there own scope. I think the admin scope will be restricted in future.

For neutron, if one admin can create router in another tenant, there will be a big risk for whole environment.

To the issue, if the router can be created successfully with OS_TENANT_NAME configured, I think it should be OK for neutron. Do you agree with this?

[Song Li (lisong-cruise)]

Set the bug #968696 also affect Neutron, waiting the Neutron members reply. If Neutron will limit the admin scope, I think we can close the issue.

[Song Li (lisong-cruise)]

@Steve, @Pablo
I saw network have TENANT_ID, and I don't think Neutron will limit the admin scope in one or two release.
I think we can add tenant_id to make it convenient for users, then remove tenant_id after Neutron limited the scope.
What's your idea?

[Steve Baker (steve-stevebaker)]

This can be reopened later once it is apparent what the right path is.