On Wed, Feb 19, 2014 at 10:27:38AM -0600, Kevin L. Mitchell wrote: > On Wed, 2014-02-19 at 13:47 +0100, Mehdi Abaakouk wrote: > > 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.
Thanks for your comments, This exactly what I have understand and what I needs, and I agree, the keystone approach looks really better to me too, but perhaps a bit more complicated to get accepted, this information is a kind of metadata associated to a project or/and a domain, that should be returned with the token validation like the service catalog. I have found a not yet accepted blueprint on this subject: https://blueprints.launchpad.net/keystone/+spec/service-metadata The funny part is the API example use quota-class as metadata key :) But whatever the approach, If a solution is accepted, I'm sure I have people to work on this. Regards, -- Mehdi Abaakouk mail: [email protected] irc: sileht
signature.asc
Description: Digital signature
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
