2014-02-25 19:48 GMT+08:00 Salvatore Orlando :
> 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 re
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. A
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
2014-02-25 11:25 GMT+08:00 Dong Liu :
> 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
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-4318b7e
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 e
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 :
> Dolph, thanks for the information you provided.
>
> Now I have two question
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 h
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:
Tanks for your reply, do you mean that it is no need to verify this in neutron,
IOW we could verify it in client side?
在 2014年2月17日，20:35，Yongsheng Gong 写道：
> 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?
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 wrote:
> keystoneclient.middlware.auth_token passes a project ID (and name, for
> convenience) to the underlying appl
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
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 wh
13 matches
Mail list logo
