My issue with using the URL is someone could easily DoS any tenant. Maybe you said that below. I only have a brief moment to scan email ATM. :)
On Mar 29, 2012, at 5:26 PM, "Kevin L. Mitchell" <kevin.mitch...@rackspace.com> wrote: > 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 _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
