Open Stack

>>1. In what ways does the current quota system not work for you? (Operations)

This is Chen from Yahoo openstack engineering team, I can explain our user case for “per-flavor-quota”.

We operates a large openstack baremetal cluster where flavors are defined based on standard hardware config (a combination of cpu code, cpu cores,  Ram,  and Disk). We need to assign quota to the tenant based on the flavor/hardware config, for example, for tenantA, allowing it to create/checkout 10 instances of flavor C2B-24-500 (6 cores Ivy Bridge + 24GB RAM + 500GB Disk) and 20 instances of flavor C2B-48-1200. I guess this is quite common in real operational environment where the resource and finance approval process are hooked in. Here, the current quota system is not able to support this user case. The total number of instances, cores, rams are not sufficient to differentiate above flavor/hardware configs and thus no way to enforce the quota allocation.

Although our user case right now is from the baremetal provisioning, we do expect to apply such per-flavor-quota mechanism to vm provisioning. The idea is the same, the quota is allocated, and more important, enforced on flavor level, instead of on the sum-up number of individual resources which loses the information of flavor-level control.

Thanks,
Chen

From: Scott Devoid <devoid at anl.gov<mailto:devoid at anl.gov>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
Date: Wednesday, April 16, 2014 at 3:40 PM
To: OpenStack Development Mailing List <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>, "openstack-operators at lists.openstack.org<mailto:openstack-operators at lists.openstack.org>" <openstack-operators at lists.openstack.org<mailto:openstack-operators at lists.openstack.org>>
Subject: [openstack-dev] Quotas: per-flavor-quotas

 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/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140420/85716085/attachment.html>