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.
thoughts? 2014-02-20 20:21 GMT+08:00 Dong Liu <willowd...@gmail.com>: > Dolph, thanks for the information you provided. > > Now I have two question: > 1. Will neutron handle this event notification in the future? > 2. I also wish neutron could verify that tenant_id is existent. > > thanks > > δΊ 2014-02-20 4:33, Dolph Mathews ει: > >> There's an open bug [1] against nova & neutron to handle notifications >> [2] from keystone about such events. I'd love to see that happen during >> Juno! >> >> [1] https://bugs.launchpad.net/nova/+bug/967832 >> [2] http://docs.openstack.org/developer/keystone/event_notifications.html >> >> On Mon, Feb 17, 2014 at 6:35 AM, Yongsheng Gong <gong...@unitedstack.com >> <mailto:gong...@unitedstack.com>> wrote: >> >> It is not easy to enhance it. If we check the tenant_id on creation, >> if should we also to do some job when keystone delete tenant? >> >> >> On Mon, Feb 17, 2014 at 6:41 AM, Dolph Mathews >> <dolph.math...@gmail.com <mailto:dolph.math...@gmail.com>> wrote: >> >> keystoneclient.middlware.auth_token passes a project ID (and >> name, for convenience) to the underlying application through the >> WSGI environment, and already ensures that this value can not be >> manipulated by the end user. >> >> Project ID's (redundantly) passed through other means, such as >> URLs, are up to the service to independently verify against >> keystone (or equivalently, against the WSGI environment), but >> can be directly manipulated by the end user if no checks are in >> place. >> >> Without auth_token in place to manage multitenant authorization, >> I'd still expect services to blindly trust the values provided >> in the environment (useful for both debugging the service and >> alternative deployment architectures). >> >> On Sun, Feb 16, 2014 at 8:52 AM, Dong Liu <willowd...@gmail.com >> <mailto:willowd...@gmail.com>> wrote: >> >> Hi stackers: >> >> I found that when creating network subnet and other >> resources, the attribute tenant_id >> can be set by admin tenant. But we did not verify that if >> the tanent_id is real in keystone. >> >> I know that we could use neutron without keystone, but do >> you think tenant_id should >> be verified when we using neutron with keystone. >> >> thanks >> _______________________________________________ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> <mailto:OpenStack-dev@lists.openstack.org> >> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/ >> openstack-dev >> >> >> >> _______________________________________________ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> <mailto:OpenStack-dev@lists.openstack.org> >> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> >> >> _______________________________________________ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> <mailto:OpenStack-dev@lists.openstack.org> >> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> >> >> >> _______________________________________________ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@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: konglingx...@huawei.com; anlin.k...@gmail.com
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
