Open Stack

 Sergio J Cazzolato wrote:

> I would to see the operators opinion in this blueprint, we need to
> understand if it is useful or it is confusing for you.
>
> https://review.openstack.org/#/c/84432/9


Sergio, I'm reposting this in a new thread since this isn't about quota
templates. Also I'm posting it to both operators and the development list.
I think we need feedback from both.

Hopefully we can get some discussion here on:
1. In what ways does the current quota system not work for you? (Operations)
2. Are there other ways to improve / change the quota system? And do these
address #1?

My hope is that we can make some small improvements that have the
possibility of landing in the Juno phase.

As clarification for anyone reading the above blueprint, this came out of
the operators summit and a thread on the operators mailing list [1]. This
blueprint defines quotas on the number of a particular flavor that a user
or project may have, e.g. "3 m1.medium and 1 m1.large instances please".
The operational need for such quotas is discussed in the mailing list.

There is another interpretation of "per-flavor-quotas", which would track
the existing resources (CPUs, RAM, etc) but do it on a per-flavor basis. As
far as I know, there is no blueprint for this, but it was suggested in the
review and on IRC. For clarity, we could call this proposal "quota
resources per flavor".

There's also a blueprint for extensible resource tracking (which I think is
part of the quota system), which has some interesting ideas. It is more
focused on closing the gap between flavor extra-specs and resource usage /
quotas. [2]

Thank you,
~ Scott

[1]
http://lists.openstack.org/pipermail/openstack-operators/2014-April/004274.html
[2] Extensible Resource Tracking *https://review.openstack.org/#/c/86050/
<https://review.openstack.org/#/c/86050/>*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140416/70a67272/attachment.html>