openstack team mailing list archive

[Eoghan Glynn <eglynn@xxxxxxxxxx>]

> 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 <kevin.mitchell@xxxxxxxxxxxxx>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>