Open Stack

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 <anlin.kong at gmail.com
> <mailto:anlin.kong at gmail.com>> wrote:
>
>
>
>     2014-02-25 11:25 GMT+08:00 Dong Liu <willowd878 at gmail.com
>     <mailto: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 <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
>             OpenStack-dev at lists.openstack.__org
>             <mailto:OpenStack-dev at lists.openstack.org>
>             http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack-dev
>             <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
>
>
>         _________________________________________________
>         OpenStack-dev mailing list
>         OpenStack-dev at lists.openstack.__org
>         <mailto:OpenStack-dev at lists.openstack.org>
>         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: konglingxian at huawei.com <mailto:konglingxian at huawei.com>;
>     anlin.kong at gmail.com <mailto:anlin.kong at gmail.com>
>
>     _______________________________________________
>     OpenStack-dev mailing list
>     OpenStack-dev at lists.openstack.org
>     <mailto: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
>