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
