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 <[email protected]> wrote: > > > 2014-02-25 11:25 GMT+08:00 Dong Liu <[email protected]>: > > 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 >>> [email protected] >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >>> >> _______________________________________________ >> OpenStack-dev mailing list >> [email protected] >> 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: [email protected]; [email protected] > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
