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.mitch...@rackspace.com> _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
