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",
    "tenant_id": "4209c294d1bb4c36acdfaa885075e0f1"
  }
}
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
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

Reply via email to