Browse Source

Add domain level limit support

This is the spec for domain level limit support.

Change-Id: Ie808328de03b19260574055f42007952e8b5a808
bp: domain-level-limit
wangxiyuan 7 months ago
parent
commit
3f365894c8
1 changed files with 246 additions and 0 deletions
  1. 246
    0
      specs/keystone/stein/domain-level-limit.rst

+ 246
- 0
specs/keystone/stein/domain-level-limit.rst View File

@@ -0,0 +1,246 @@
1
+..
2
+ This work is licensed under a Creative Commons Attribution 3.0 Unported
3
+ License.
4
+
5
+ http://creativecommons.org/licenses/by/3.0/legalcode
6
+
7
+==================================
8
+Domain Level Unified Limit Support
9
+==================================
10
+
11
+`bp domain-level-limit <https://blueprints.launchpad.net/keystone/+spec/domain-level-limit>`_
12
+
13
+Currently Unified limit in Keystone is for project level. It can't cover the
14
+domain level case.
15
+
16
+Problem Description
17
+===================
18
+
19
+In some case, especially for Public Cloud, an account in the cloud is usually
20
+a domain in Keystone. In the domain(account), the cloud provider allow the user
21
+to create his own projects, users, or roles. So of course, these resource
22
+should be handled by limit as well. From service provider sight, he needs the
23
+ability to control the cloud account's limit. But Keystone now doesn't support
24
+domain level limit. Suppose a case: There is a domain(account) has 3 projects,
25
+the service provider want to limit each project can create 10 vms, but the
26
+total vms in the domain should be less than 20. Keystone can't handle this case
27
+currently.
28
+
29
+
30
+Proposed Change
31
+===============
32
+
33
+Database change
34
+---------------
35
+
36
+Create a new column called `domain_id` to limit table to store the limit's
37
+`domain_id` proprety.
38
+
39
+API change
40
+----------
41
+
42
+Since the `domain` related APIs and resources are still alive in Keystone, API
43
+callers usually treat `domain` different with `project`. So for unified limit
44
+APIs, we'll add `domain_id` as well.
45
+
46
+**Request:** ``POST /limits``
47
+
48
+Add `domain_id` into request body. Either `project_id` or `domain_id` must be
49
+provided. The body is like:
50
+
51
+**Request Body**
52
+
53
+.. code-block:: json
54
+
55
+    {
56
+        "limits":[
57
+            {
58
+                "service_id": "9408080f1970482aa0e38bc2d4ea34b7",
59
+                "project_id": "3a705b9f56bb439381b43c4fe59dccce",
60
+                "region_id": "RegionOne",
61
+                "resource_name": "snapshot",
62
+                "resource_limit": 5
63
+            },
64
+            {
65
+                "service_id": "9408080f1970482aa0e38bc2d4ea34b7",
66
+                "domain_id": "4d705b9f56bb296381b43c4fe59da34d",
67
+                "resource_name": "volume",
68
+                "resource_limit": 10,
69
+                "description": "Number of volumes for domain 4d705b9f56bb296381b43c4fe59da34d"
70
+            }
71
+        ]
72
+    }
73
+
74
+**Request:** ``GET /limits/{limit_id}``
75
+
76
+The response body will contain `domain_id` as well. If the `project_id` in the
77
+response body is None, it means this is a domain level limit.
78
+
79
+**Response Body**
80
+
81
+.. code-block:: json
82
+
83
+    {
84
+        "limit": {
85
+            "resource_name": "volume",
86
+            "region_id": null,
87
+            "links": {
88
+                "self": "http://10.3.150.25/identity/v3/limits/25a04c7a065c430590881c646cdcdd58"
89
+            },
90
+            "service_id": "9408080f1970482aa0e38bc2d4ea34b7",
91
+            "project_id": null,
92
+            "domain_id": "3a705b9f56bb439381b43c4fe59dccce",
93
+            "id": "25a04c7a065c430590881c646cdcdd58",
94
+            "resource_limit": 11,
95
+            "description": null
96
+        }
97
+    }
98
+
99
+**Request:** ``GET /limits``
100
+
101
+The response body is similar with GET /limits. Add the `domain_id` filter to
102
+query the specified limits.
103
+
104
+Model change
105
+------------
106
+Now both `flat` model and `strict-two-level` model are only for project level.
107
+
108
+Non hierarchical model
109
+^^^^^^^^^^^^^^^^^^^^^^
110
+Like Flat model, it is non hierarchical. So domain level limit in this kind of
111
+model is non hierarchical as well.
112
+
113
+Hierarchical model
114
+^^^^^^^^^^^^^^^^^^
115
+Like strict-two-level model, For this kind of model, Every project's limit in
116
+a domain should not be larger than the domain's limit.
117
+
118
+Of course, The domain level be considered as one level In strict-two-level
119
+model currently, the depth of project should not greater than
120
+2. Like::
121
+
122
+  Project(level-1)
123
+       |
124
+  Project(level-2)
125
+
126
+Once domain level limit is supported, the
127
+structure will be::
128
+
129
+  Domain(level-1)
130
+    |
131
+  Project(level-2)
132
+
133
+
134
+Error Handler
135
+-------------
136
+
137
+The behavior for error handler will not be changed, It'll keep the same with
138
+the enforcement model. See the detail in the `enforcement`_ part of
139
+strict-two-level-enforcement-model spec.
140
+
141
+.. _`enforcement`: http://specs.openstack.org/openstack/keystone-specs/specs/keystone/rocky/strict-two-level-enforcement-model.html#enforcement-diagrams
142
+
143
+Backward compatibility
144
+----------------------
145
+The unified limit feature is still experimental in Keystone and there is no
146
+customer currently. So there is not need to consider the backward compatibility
147
+now.
148
+
149
+Alternatives
150
+------------
151
+
152
+Database change
153
+^^^^^^^^^^^^^^^
154
+We can reuse the `project_id` column to store `domain_id`. At database layer,
155
+`domain_id` can be treat the same as `project_id`.
156
+
157
+But this change would make the code much complex. Some code for dealing with
158
+`project_id` and `domain_id` would be added of which the user experience is not
159
+good.
160
+
161
+Hierarchical model
162
+^^^^^^^^^^^^^^^^^^
163
+For hierarchical model, we can treat domain level as the top level which does
164
+not consume the project level depth. Like::
165
+
166
+  Domain
167
+    |
168
+  Project-level1
169
+    |
170
+  Project-level2
171
+
172
+
173
+But if so, the depth will be more than 2 which will break strict two concept.
174
+The strict-two-level-enforcement-model spec has a good `explanation`_
175
+
176
+.. _explanation: http://specs.openstack.org/openstack/keystone-specs/specs/keystone/rocky/strict-two-level-enforcement-model.html#optimized-usage-calculation
177
+
178
+Security Impact
179
+---------------
180
+
181
+N/A
182
+
183
+Notifications Impact
184
+--------------------
185
+
186
+N/A
187
+
188
+
189
+Other End User Impact
190
+---------------------
191
+
192
+This is a cloud admin feature. It doesn't impact end user through APIs. If the
193
+end user is domain level, he may have limitation for cloud resource then.
194
+
195
+
196
+Performance Impact
197
+------------------
198
+
199
+N/A
200
+
201
+Other Deployer Impact
202
+---------------------
203
+
204
+N/A
205
+
206
+Developer Impact
207
+----------------
208
+
209
+N/A
210
+
211
+Implementation
212
+==============
213
+
214
+Assignee(s)
215
+-----------
216
+
217
+Primary assignee:
218
+  wangxiyuan<wangxiyuan@huawei.com>
219
+
220
+Work Items
221
+----------
222
+
223
+* Update database schema
224
+* Update POST/GET /limits /limits/{limit_id} APIs.
225
+* Update limit model check function.
226
+* Update related docs.
227
+
228
+
229
+Dependencies
230
+============
231
+
232
+N/A
233
+
234
+
235
+Documentation Impact
236
+====================
237
+
238
+Domain level limit support should be documented in admin guide.
239
+
240
+
241
+References
242
+==========
243
+
244
+* OpenStack Public Cloud WG `requirement`_
245
+
246
+.. _requirement: https://bugs.launchpad.net/openstack-publiccloud-wg/+bug/1771581

Loading…
Cancel
Save