From 3f365894c8174f67ea5183d5f605f35d44f42565 Mon Sep 17 00:00:00 2001 From: wangxiyuan Date: Tue, 4 Sep 2018 11:34:19 +0800 Subject: [PATCH] Add domain level limit support This is the spec for domain level limit support. Change-Id: Ie808328de03b19260574055f42007952e8b5a808 bp: domain-level-limit --- specs/keystone/stein/domain-level-limit.rst | 246 ++++++++++++++++++++ 1 file changed, 246 insertions(+) create mode 100644 specs/keystone/stein/domain-level-limit.rst diff --git a/specs/keystone/stein/domain-level-limit.rst b/specs/keystone/stein/domain-level-limit.rst new file mode 100644 index 00000000..5f45a630 --- /dev/null +++ b/specs/keystone/stein/domain-level-limit.rst @@ -0,0 +1,246 @@ +.. + This work is licensed under a Creative Commons Attribution 3.0 Unported + License. + + http://creativecommons.org/licenses/by/3.0/legalcode + +================================== +Domain Level Unified Limit Support +================================== + +`bp domain-level-limit `_ + +Currently Unified limit in Keystone is for project level. It can't cover the +domain level case. + +Problem Description +=================== + +In some case, especially for Public Cloud, an account in the cloud is usually +a domain in Keystone. In the domain(account), the cloud provider allow the user +to create his own projects, users, or roles. So of course, these resource +should be handled by limit as well. From service provider sight, he needs the +ability to control the cloud account's limit. But Keystone now doesn't support +domain level limit. Suppose a case: There is a domain(account) has 3 projects, +the service provider want to limit each project can create 10 vms, but the +total vms in the domain should be less than 20. Keystone can't handle this case +currently. + + +Proposed Change +=============== + +Database change +--------------- + +Create a new column called `domain_id` to limit table to store the limit's +`domain_id` proprety. + +API change +---------- + +Since the `domain` related APIs and resources are still alive in Keystone, API +callers usually treat `domain` different with `project`. So for unified limit +APIs, we'll add `domain_id` as well. + +**Request:** ``POST /limits`` + +Add `domain_id` into request body. Either `project_id` or `domain_id` must be +provided. The body is like: + +**Request Body** + +.. code-block:: json + + { + "limits":[ + { + "service_id": "9408080f1970482aa0e38bc2d4ea34b7", + "project_id": "3a705b9f56bb439381b43c4fe59dccce", + "region_id": "RegionOne", + "resource_name": "snapshot", + "resource_limit": 5 + }, + { + "service_id": "9408080f1970482aa0e38bc2d4ea34b7", + "domain_id": "4d705b9f56bb296381b43c4fe59da34d", + "resource_name": "volume", + "resource_limit": 10, + "description": "Number of volumes for domain 4d705b9f56bb296381b43c4fe59da34d" + } + ] + } + +**Request:** ``GET /limits/{limit_id}`` + +The response body will contain `domain_id` as well. If the `project_id` in the +response body is None, it means this is a domain level limit. + +**Response Body** + +.. code-block:: json + + { + "limit": { + "resource_name": "volume", + "region_id": null, + "links": { + "self": "http://10.3.150.25/identity/v3/limits/25a04c7a065c430590881c646cdcdd58" + }, + "service_id": "9408080f1970482aa0e38bc2d4ea34b7", + "project_id": null, + "domain_id": "3a705b9f56bb439381b43c4fe59dccce", + "id": "25a04c7a065c430590881c646cdcdd58", + "resource_limit": 11, + "description": null + } + } + +**Request:** ``GET /limits`` + +The response body is similar with GET /limits. Add the `domain_id` filter to +query the specified limits. + +Model change +------------ +Now both `flat` model and `strict-two-level` model are only for project level. + +Non hierarchical model +^^^^^^^^^^^^^^^^^^^^^^ +Like Flat model, it is non hierarchical. So domain level limit in this kind of +model is non hierarchical as well. + +Hierarchical model +^^^^^^^^^^^^^^^^^^ +Like strict-two-level model, For this kind of model, Every project's limit in +a domain should not be larger than the domain's limit. + +Of course, The domain level be considered as one level In strict-two-level +model currently, the depth of project should not greater than +2. Like:: + + Project(level-1) + | + Project(level-2) + +Once domain level limit is supported, the +structure will be:: + + Domain(level-1) + | + Project(level-2) + + +Error Handler +------------- + +The behavior for error handler will not be changed, It'll keep the same with +the enforcement model. See the detail in the `enforcement`_ part of +strict-two-level-enforcement-model spec. + +.. _`enforcement`: http://specs.openstack.org/openstack/keystone-specs/specs/keystone/rocky/strict-two-level-enforcement-model.html#enforcement-diagrams + +Backward compatibility +---------------------- +The unified limit feature is still experimental in Keystone and there is no +customer currently. So there is not need to consider the backward compatibility +now. + +Alternatives +------------ + +Database change +^^^^^^^^^^^^^^^ +We can reuse the `project_id` column to store `domain_id`. At database layer, +`domain_id` can be treat the same as `project_id`. + +But this change would make the code much complex. Some code for dealing with +`project_id` and `domain_id` would be added of which the user experience is not +good. + +Hierarchical model +^^^^^^^^^^^^^^^^^^ +For hierarchical model, we can treat domain level as the top level which does +not consume the project level depth. Like:: + + Domain + | + Project-level1 + | + Project-level2 + + +But if so, the depth will be more than 2 which will break strict two concept. +The strict-two-level-enforcement-model spec has a good `explanation`_ + +.. _explanation: http://specs.openstack.org/openstack/keystone-specs/specs/keystone/rocky/strict-two-level-enforcement-model.html#optimized-usage-calculation + +Security Impact +--------------- + +N/A + +Notifications Impact +-------------------- + +N/A + + +Other End User Impact +--------------------- + +This is a cloud admin feature. It doesn't impact end user through APIs. If the +end user is domain level, he may have limitation for cloud resource then. + + +Performance Impact +------------------ + +N/A + +Other Deployer Impact +--------------------- + +N/A + +Developer Impact +---------------- + +N/A + +Implementation +============== + +Assignee(s) +----------- + +Primary assignee: + wangxiyuan + +Work Items +---------- + +* Update database schema +* Update POST/GET /limits /limits/{limit_id} APIs. +* Update limit model check function. +* Update related docs. + + +Dependencies +============ + +N/A + + +Documentation Impact +==================== + +Domain level limit support should be documented in admin guide. + + +References +========== + +* OpenStack Public Cloud WG `requirement`_ + +.. _requirement: https://bugs.launchpad.net/openstack-publiccloud-wg/+bug/1771581