[openstack-dev] Quota Management

Scott Devoid devoid at anl.gov
Thu Apr 3 16:12:46 UTC 2014


Adding the Operators list to this since I think they will have some useful
comments.

My experience is that the current Nova quotas are not entirely useful. In
our environment we have a limited number of machines with 32 cores and 1TB
of ram (tens), and a large number with 8 cores and 32GB of ram (hundreds).
Aside from limits on the # of instances, the quota system would see the use
of 32 small machines as equivalent to the use of one big machine.
Economically and operationally these to cases are very different.

As a suggestion, how hard would it be to allow operators to create quotas
on the # of a given flavor that a tenant/domain may want to use?


On Thu, Apr 3, 2014 at 10:02 AM, Cazzolato, Sergio J <
sergio.j.cazzolato at intel.com> wrote:

>  Hi All,
>
>
>
> I’d like to know your thoughts regarding Quota Management… I’ve been
> contributing to this topic for icehouse and noticed some issues and
> discussions around its implementation like code is duplicated, synch
> problems with database, not having an homogeneous logic, etc… so I was
> thinking that maybe a centralized implementation could be a solution for
> this… As far as I know there was a discussion during the last summit and
> the decision was to use Keystone for a Centralized Quota Management
> solution but I don’t have the details on that discussion… Also I was
> looking at Boson (https://wiki.openstack.org/wiki/Boson) that seems to be
> a nice solution for this and also addresses the scenario where Nova is
> deployed in a multi-cell manner and some other interesting things.
>
>
>
> Sergio
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140403/dce60d19/attachment.html>


More information about the OpenStack-dev mailing list