openstack team mailing list archive

["Kevin L. Mitchell" <kevin.mitchell@xxxxxxxxxxxxx>]

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.mitchell@xxxxxxxxxxxxx>