Open Stack

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: sileht at sileht.net
irc: sileht
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140225/565091bf/attachment.pgp>