Re: [openstack-dev] [Nova] status of quota class

2014-05-28 Thread Mark McLoughlin
On Wed, 2014-02-19 at 10:27 -0600, Kevin L. Mitchell wrote:
 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.

Just for reference, we discussed the fact that this code was unused two
years ago:

  https://lists.launchpad.net/openstack/msg12200.html

and I see Joe has now completed the process of removing it again:

  https://review.openstack.org/75535
  https://review.openstack.org/91480
  https://review.openstack.org/91699
  https://review.openstack.org/91700

Mark.


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] [Nova] status of quota class

2014-02-19 Thread Mehdi Abaakouk
Hi, 

I have recently dig into the quota class in nova and some related
subject on the ML and discovered that quota class code exists but it is
not usable.

An API V2 extension exists to manipulate quota class, these one are
stored into the database.

The quota driver engine handles quota class too, and attends to have the
'quota_class' argument into the nova RequestContext set.

But 'quota_class' is never set when a nova RequestContext is created.

The quota class API V3 have been recently removed due to the unfinished work:
https://github.com/openstack/nova/commit/1b15b23b0a629e00913a40c5def42e5ca887071c


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

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 ? 

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.



Best Regards, 

-- 
Mehdi Abaakouk
mail: sil...@sileht.net
irc: sileht


signature.asc
Description: Digital signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Nova] status of quota class

2014-02-19 Thread Kevin L. Mitchell
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.mitch...@rackspace.com
Rackspace


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev