Open Stack

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.mitchell at 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.mitchell at rackspace.com>
> 
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack at lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp