> > > Eoghan Glynn wrote: > > > > > > - how is the mapping between project and quota-class established? > > > I was expecting a project_quota_class_association table or > > > some-such in the nova DB. Is this association maintained by > > > keystone instead? > > > > > > - is the quota_class attribute currently being set on the request > > > context anywhere in the dispatch path? Is the idea that the > > > auth > > > middleware takes care of this? > > > > Kevin Mitchell wrote: > > > > The basic answer is that there isn't anything in nova right now > > that > > does this, partly because it's a slightly difficult question to > > answer > > correctly for everyone. In my testing environment, for instance, I > > use > > a Turnstile preprocessor to set the quota_class attribute on the > > request > > context to be the same as the selected rate limit class. > > > > I envisioned that, ultimately, the quota_class would be set by the > > authentication processing middleware(s), but I'm not against adding > > an association to nova to manage that. > > One more follow-up question on this. > > 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. > > 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. > > 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 guess the other alternative would be to simply create new quota classes for each permutation of resource limits required, e.g. premium-compute-basic-storage, basic-compute-premium-storage etc. We'd get asome proliferation on the number of quota classes, but in realistic scenarios it wouldn't go combinatorial. Cheers, Eoghan _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
