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 <[email protected]> Rackspace _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
