[Openstack] Quota classes

Kevin L. Mitchell kevin.mitchell at rackspace.com
Wed Apr 4 14:50:31 UTC 2012


On Wed, 2012-04-04 at 07:21 -0400, Eoghan Glynn wrote:
> So IIUC the mechanism as it currently stands implies a 1:M
> mapping between quota classes and projects/tenants. Only a single
> quota class may be selected for each request context, so *all* the
> individual hard limits for the different resource types encompassed
> by that class are inherited as default quotas for the request.

Yes, that is correct.

> But might there be a usecase for mutiple quota classes applying to
> an individual project (for different resource types)? 
> 
> e.g. compute-hungry/storage-light customers might select the
> premium package for instances/cores/RAM combined with the basic
> package for volumes/gigabytes (or vice versa for storage-heavy
> but narrowly-scaled apps).
> 
> If we were to go down that road, we'd require an N:M association
> between quota class names & projects, right? Or equivalently, a
> 1:M mapping between quota class IDs and projects.

Indeed we could.  I opted not to support that possibility in my first
cut at quota classes…

> Also the single quota class name in the request context would 
> have to be replaced with a list of either quota class IDs or
> (quota class name, resource type) pairs.

I think it'd be better to have it be replaced with a list of quota class
names; for a given quota class, you define only the specific resources
you're interested in, then use a first-applies rule to deal with
conflicts.
-- 
Kevin L. Mitchell <kevin.mitchell at rackspace.com>





More information about the Openstack mailing list