2014-02-25 19:48 GMT+08:00 Salvatore Orlando sorla...@nicira.com:
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
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
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.
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
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
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,
2014-02-25 11:25 GMT+08:00 Dong Liu willowd...@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:
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
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
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.comwrote:
keystoneclient.middlware.auth_token passes a project ID (and name, for
convenience)
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
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
12 matches
Mail list logo
