[openstack-dev] [Neutron]Do you think tanent_id should be verified

Salvatore Orlando sorlando at nicira.com
Tue Feb 25 11:48:48 UTC 2014


I understand the fact that resources with invalid tenant_ids can be created
(only with admin rights at least for Neutron) can be annoying.

However, I support Jay's point on cross-project interactions. If tenant_id
validation (and orphaned resource management) can't be efficiently handled,
then I'd rather let 3rd party scripts dealing with orphaned and invalid
resources.

I reckon that it might be worth experimenting whether the notifications
sent by Keystone (see Dolph's post on this thread) can be used to deal with
orphaned resources.
For tenant_id validation, anything involving an extra round trip to
keystone would not be efficient in my opinion. If there is a way to perform
this validation in the same call which validates the tenant auth_token then
it's a different story.
Notifications from keystone *could* be used to build a local (persistent
perhaps) cache of active tenant identifiers. However, this would require
reliable notifications, as well as appropriate cache management, which is
often less simple than what it looks like.

Salvatore


On 25 February 2014 05:23, Lingxian Kong <anlin.kong at gmail.com> wrote:

>
>
> 2014-02-25 11:25 GMT+08:00 Dong Liu <willowd878 at gmail.com>:
>
> Thanks Jay, now I know maybe neutron will not handle tenant
>> creating/deleting notifications which from keystone.
>>
>> There is another question, such as creating subnet request body:
>> {
>>   "subnet": {
>>     "name": "test_subnet",
>>     "enable_dhcp": true,
>>     "network_id": "57596b26-080d-4802-8cce-4318b7e543d5",
>>     "ip_version": 4,
>>     "cidr": "10.0.0.0/24",
>>     "tenant_id": "4209c294d1bb4c36acdfaa885075e0f1"
>>
>
> So, this is exactly what I mean for 'temant_id' here that should be
> validated.
> I insist this could be done via some middleware or else.
>
>   }
>> }
>> As we know, the tenant_id can only be specified by admin tenant.
>>
>> In my test, the tenant_id I filled in the body can be any string (e.g., a
>> name, an uuid, etc.) But I think this tenant existence (I mean if the
>> tenant exists in keystone) should be verified, if not, the subnet I created
>> will be an useless resource.
>>
>> Regards,
>> Dong Liu
>>
>>
>> On 2014-02-25 0:22, Jay Pipes Wrote:
>>
>>> On Mon, 2014-02-24 at 16:23 +0800, Lingxian Kong wrote:
>>>
>>>> I think 'tenant_id' should always be validated when creating neutron
>>>> resources, whether or not Neutron can handle the notifications from
>>>> Keystone when tenant is deleted.
>>>>
>>>
>>> -1
>>>
>>> Personally, I think this cross-service request is likely too expensive
>>> to do on every single request to Neutron. It's already expensive enough
>>> to use Keystone when not using PKI tokens, and adding another round trip
>>> to Keystone for this kind of thing is not appealing to me. The tenant is
>>> already "validated" when it is used to get the authentication token used
>>> in requests to Neutron, so other than the scenarios where a tenant is
>>> deleted in Keystone (which, with notifications in Keystone, there is now
>>> a solution for), I don't see much value in the extra expense this would
>>> cause.
>>>
>>> Best,
>>> -jay
>>>
>>>
>>>
>>> _______________________________________________
>>> OpenStack-dev mailing list
>>> OpenStack-dev at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
>
> --
> *---------------------------------------*
> *Lingxian Kong*
> Huawei Technologies Co.,LTD.
> IT Product Line CloudOS PDU
> China, Xi'an
> Mobile: +86-18602962792
> Email: konglingxian at huawei.com; anlin.kong at gmail.com
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140225/0c65d071/attachment.html>


More information about the OpenStack-dev mailing list