Salvatore, thank you very much for your reply.
I know that there was a proposal[1] to handle the message security
stuff. For this proposal implementation, there was a blueprint[2] of
keystone will merge in Icehouse.
I'm looking forward to the notification handling could implemente in
Juno. Although I'm a new bee here, if it is possible, I wish I can take
part in this in the days to come.
[1] https://wiki.openstack.org/wiki/MessageSecurity
[2] https://blueprints.launchpad.net/keystone/+spec/key-distribution-server
Regards,
Dong Liu
On 2014-02-25 19:48, Salvatore Orlando Wrote:
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]
<mailto:[email protected]>> wrote:
2014-02-25 11:25 GMT+08:00 Dong Liu <[email protected]
<mailto:[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 <http://10.0.0.0/24>",
"tenant_id": "__4209c294d1bb4c36acdfaa885075e0__f1"
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].__org
<mailto:[email protected]>
http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack-dev
<http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
_________________________________________________
OpenStack-dev mailing list
[email protected].__org
<mailto:[email protected]>
http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack-dev
<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 <tel:%2B86-18602962792>
Email: [email protected] <mailto:[email protected]>;
[email protected] <mailto:[email protected]>
_______________________________________________
OpenStack-dev mailing list
[email protected]
<mailto:[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
_______________________________________________
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev