← Back to team overview

openstack team mailing list archive

Re: Quota classes

 

On Mon, 2012-03-19 at 10:58 -0400, Jay Pipes wrote:
> Because more services than Nova can/should have Quotas/limits. Glance 
> would like to piggy back on some common quota code if possible, instead 
> of inventing something new :)

I'll comment that I've also been doing some thinking of how to make the
quota code pluggable, perhaps even supporting an external service.  I
was initially thinking another service utilizing our rabbitmq-based RPC,
but it could just as easily be REST-based.  The caveat there, though, is
that we really should have some sort of caching, which brings up the
whole cache invalidation thing…

> But, that said, I would not be opposed to having the quota/limits stuff 
> outside of Keystone. I think Kevin's Turnstile is a pretty good solution 
> that offers middleware that does distributed ratelimiting in a flexible 
> architecture and has some nice advantages over the Swift ratelimit 
> middleware, including having a control thread that allows admins to 
> reconfigure the ratelimit middleware without restarting the service that 
> houses the middleware -- just send a message to the control daemon's 
> pubsub channel...
> 
> Would be awesome if the benefits of the Swift middleware -- namely, the 
> ability to use existing Memcache infrastructure -- were married to the 
> Turnstile solution, though. :)

Feel free to submit (more) pull-reqs ;)

To be honest, I view rate limits and quotas as separate things, because
of how they apply; quotas are simple enforced counts, whereas rate
limits are time-limited counts (implemented in Turnstile as leaky
buckets).  I don't really understand why nova has exposed them through
the same interface (/limits returns both as two separate dictionaries),
but *shrug*.  (I am certainly not recommending that we separate them, by
the way ;)
-- 
Kevin L. Mitchell <kevin.mitchell@xxxxxxxxxxxxx>



References