openstack team mailing list archive

[Eoghan Glynn <eglynn@xxxxxxxxxx>]

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