> > 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. 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