Domain-level quota managements

Bug #1771581 reported by Tobias Rydberg on 2018-05-16
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OpenStack Public Cloud WG
High
wangxiyuan

Bug Description

Quotas should be assignable at the domain level such that all projects in a domain are re-allocated their quota from the domain level. This allows public cloud providers to allocate quota at the customer level and then customer is responsible for redistrbuting those allowances across their projects. Multi-region support as well - if that exist.

"(Henry Nash): In fact, no change needed in Keystone. Domains are actually represented in keystone as projects with a special attribute (is_domain=True). Hence all that is needed is that services that have quotas to handle the ""root"" of a project hierarchy (which is a project representing the domain) as being able to hold a quota. Q (tobberydberg): So subprojects of ""domain"" project cannot allocate more resourses in total than the quota of the ""domain"" project?Well, that would depend on the quota model chosen (i.e. do you support over-commit or not). There is a cross-project spec that is in the works which would make keystone the common store of quoto limits, but the actual algorithms and calcaulations will remain in the individual services.

(Tim Bell) This is very close to the nested quota model which the scientific working group has been encouraging (https://openstack-in-production.blogspot.fr/2016/04/resource-management-at-cern.html). There is clearly further work to be done after the quotas (such as customers can upload an image which is available to projects lower in the tree) but quotas is the first step."

Reference specs:
https://specs.openstack.org/openstack/keystone-specs/specs/keystone/ongoing/unified-limits.html
https://etherpad.openstack.org/p/BOS-forum-quotas

Changed in openstack-publiccloud-wg:
importance: Undecided → High
Lance Bragstad (lbragstad) wrote :

We have a specification that might address this up for review for Rocky [0].

[0] https://review.openstack.org/#/c/540803/

Tobias Rydberg (tobberydberg) wrote :

Solution mentioned in comment #1 was discussed at the Forum session in Vancouver. Strict-two-level solves my use case for this. (thanks @lbragstad + team) How about other operators? Do you have the need for more depth?

Changed in openstack-publiccloud-wg:
status: New → In Progress
melanie witt (melwitt) wrote :

We're looking at beginning adoption of keystone unified limits in Nova via oslo.limit this cycle (Stein). We're going to discuss it on Friday at the PTG at the Nova room [1].

[1] https://etherpad.openstack.org/p/nova-ptg-stein L293

wangxiyuan (wangxiyuan) on 2018-09-27
Changed in openstack-publiccloud-wg:
assignee: nobody → wangxiyuan (wangxiyuan)
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers