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

Reply via email to