Open Stack

On Wed, 2014-02-19 at 13:47 +0100, Mehdi Abaakouk wrote:
> But 'quota_class' is never set when a nova RequestContext is created.

When I created quota classes, I envisioned the authentication component
of the WSGI stack setting the quota_class on the RequestContext, but
there was no corresponding concept in Keystone.  We need some means of
identifying groups of tenants.

> So my question, what is the plan to finish the 'quota class' feature ? 

I currently have no plan to work on that, and I am not aware of any such
work.

> Can I propose a blueprint for the next cycle to store the mapping between
> project and a quota_class into nova itself, to finish this feature ? 

Of course; anyone can propose a blueprint.  Who will you have work on
the feature?

> ie: add a new API endpoint to set a quota_class to a project, store that
> into the db and change the quota engine to read the quota_class from the
> db instead of the RequestContext.

Reading the quota class from the db sounds like a bad fit to me; this
really feels like something that should be stored in Keystone, since
it's authentication-related data.  Additionally, if the attribute is in
Keystone, other services may take advantage of it.  The original goal of
quota classes was to make it easier to update the quotas of a given
tenant based on some criteria, such as the service level they've paid
for; if a customer upgrades (or downgrades) their service level, their
quotas should change to match.  This could be done by manually updating
each quota that affects them, but a single change to a single attribute
makes better sense.
-- 
Kevin L. Mitchell <kevin.mitchell at rackspace.com>
Rackspace