Hi,
There was an ongoing project of delimiter for Cross Project Quota
Management.
But I don't know the current status.
Kindly have a look at it.
https://review.openstack.org/#/c/284454/
More discussions are required on this.As more and more projects or
services are having the concept of quotas,Quota as a service can also be
thought of.Anyway more discussions are required on this topic.
best regards,
sajeesh
________________________________________
From: Jay Pipes [[email protected]]
Sent: 13 December 2016 18:55:14
To: [email protected]
Subject: Re: [openstack-dev] [keystone][nova]Quotas: Store resources and limits
in the Keystone
On 12/13/2016 08:09 AM, Kseniya Tychkova wrote:
> Hi,
> I would like to share a spec [1] with you.
> The main idea of this spec is to start a discussion about quota
> management in the OpenStack.
>
> Quotas are scattered across OpenStack services. Each service defines
> it's own model and API for
> managing resource's limits. Because of that, there are several problems:
>
> * Names of the resources and resource-service mapping are hardcoded.
> They are hardcoded in the service code (Nova, for example) and it
> should be hardcoded in the client code (Horizon, for example).
>
> * There is no centralized quota management for OpenStack projects.
> * Cinder, Nova and Neutron support (or going to support) hierarchical
> quotas in different ways.
>
> There should be a single point of managing quotas in OpenStack.
> Keystone looks like a proper place to store resource's limits because:
>
> * Keystone stores projects
> * Limits are belong to project.
Another excellent reason to store quota limits in Keystone is because
virtually all non-list operations require some interaction with quota
limits, and requiring Nova (or Cinder or Neutron) to call out to yet
another service each time the user makes one of those non-list
operations is sub-optimal when Nova is already making a call to Keystone
for authentication.
The alternative is to have a separate REST API service just for storing
and returning the quota limits and have Nova, Cinder and Neutron call
this new service each time a non-list operation is made. While this is
possible, it's just yet another service that needs to be managed and
deployed by all installations of OpenStack.
Best,
-jay
> There are a lot of possible issues with “store limits in Keystone”
> approach. But all of them can be discussed
> and such discussion should lead to the good solution for quotas
> management in Openstack.
>
> Please take a look at the spec when you have time and share your ideas
> or concerns.
>
> [1] https://review.openstack.org/#/c/363765/
>
>
> Kind regards,
> Kseniya
>
>
>
>
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: [email protected]?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
