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/>*
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
