Merge "Add domain level limit support"

This commit is contained in:
Zuul 2018-12-14 10:28:05 +00:00 committed by Gerrit Code Review
commit 615cb26294
1 changed files with 246 additions and 0 deletions

View File

@ -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 <https://blueprints.launchpad.net/keystone/+spec/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<wangxiyuan@huawei.com>
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