> Kevin Mitchell wrote: > I recently got the quota classes stuff merged into master (after the RC > branch for Essex was cut, of course). After I had completed that work, > I started thinking about quotas in general, and I think there's a better > way to organize how we do quotas in the first place. One potential side > effect I see of that possible work would be to address this > particular feature. > > My idea here is not really very well fleshed out or architected yet, and > I have other things I'm focusing on right now (caching), but perhaps I > should mention them on the list, in order to get a discussion going…and > perhaps a summit discussion of the topic would be in order?
Yep, that's a good idea. Let me know if you'd be interested in collaborating on a summit session. I'll have a detailed look at your recent work on quota classes before responding to your quota infrastructure thoughts below ... but on a first look, definitely sounds sane. Cheers, Eoghan > The basic thought I had here was to create a "quota manager" or > "quota > plugin" infrastructure, instead of a bunch of fixed functions in > quota.py that we use to test certain specific quotas. Having it as a > plugin that you specify in configuration means you can easily > substitute > out the default implementation, if necessary—maybe you want quotas to > be > enforced across several cells instead of just one, for instance. > Then, > checking a quota would be a matter of simply calling a method on the > quota plugin class. > > The side effect is that, in order to properly impose quotas in a > flexible architecture, you would need to keep the quota plugin > up-to-date on the current numbers of whatever resource is being > limited > anyway—in the example above, of having one quota applied across a > number > of cells, you don't want to have to ask each cell how many instances > the > user currently has. That makes implementation of your headroom > concept > pretty trivial, and I could see it implemented by attaching a little > more data to the /limits endpoint's returned data. > > (The current quota code has to count how many instances there are > each > time it checks the quota; I think other parts that use quotas may do > the > counting themselves and just ask quota.py what the upper limit is.) > -- > Kevin L. Mitchell <[email protected]> > > > _______________________________________________ > Mailing list: https://launchpad.net/~openstack > Post to : [email protected] > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp > _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : [email protected] Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
