On Thu, 2012-03-29 at 22:58 +0100, Day, Phil wrote: > - As you get the tenant id from the context I assume this module has > to come after the authentication in the pipeline.
Yes, I have made that assumption. It seems reasonable, given that the existing rate-limit middleware is right after authentication as well. > Have you thought about using the tenant_id in the URL instead ? (I'm > thinking of the case where you want rate limit requests into the > authentication system as well as Nova itself). No, I haven't. I don't trust the user, which is where the tenant_id in the URL comes from. I do trust the auth system, which is why I want to use the tenant ID from the context. (And yes, you could argue that authz would prevent their access to other tenants anyway, but why make nova have to check authz if rate limiting would stop them in the first place?) As for rate limiting requests into the authentication system, I'd suggest using a Limit subclass which uses the remote IP address in place of a tenant ID, at least for the user endpoint. I don't think we want any rate limiting at all on the service side of Keystone; our current architecture means that Keystone is going to be hit a *lot*: at least once for each request that hits Nova, and more in certain cases (i.e., instance boot, where we'll have to hit quantum and glance as well). > - Does this work for EC2 as well as OSAPI ? Actually, it didn't occur to me to test, given that I don't really use the EC2 API. I don't think there's anything in the basic architecture which would be incompatible with EC2; the only possible sticking point that occurs to me is the URL construction in nova_limits:NovaClassLimit.route(): if the URL specified is prefixed with '/v1.1/' or '/v2/', the version identifier is dropped (otherwise the route wouldn't match). That would be easy to work around; simply extend NovaClassLimit and override route() to do the appropriate transformation for EC2. Any EC2 experts want to weigh in? -- Kevin L. Mitchell <kevin.mitch...@rackspace.com> _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
