| Thread Previous • Date Previous • Date Next • Thread Next |
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>
| Thread Previous • Date Previous • Date Next • Thread Next |
