Browse Source

Switch to stestr

According to Openstack summit session [1],
stestr is maintained project to which all Openstack projects should migrate.
Let's switch to stestr as other projects have already moved to it.

This change also fixes a bunch of D001 violations where lines are too
long in .rst documents.

[1] https://etherpad.openstack.org/p/YVR-python-pti

Change-Id: Ic20ae60d9020896690c5e7f07124d7500ffd3d2d
Vu Cong Tuan 9 months ago
parent
commit
4fe55f0e82
6 changed files with 135 additions and 92 deletions
  1. 1
    1
      .gitignore
  2. 4
    0
      .stestr.conf
  3. 0
    4
      .testr.conf
  4. 1
    1
      requirements.txt
  5. 128
    85
      specs/keystone/rocky/define-default-roles.rst
  6. 1
    1
      tox.ini

+ 1
- 1
.gitignore View File

@@ -7,4 +7,4 @@ build
7 7
 *.swp
8 8
 *.swo
9 9
 *.pyc
10
-.testrepository
10
+.stestr/

+ 4
- 0
.stestr.conf View File

@@ -0,0 +1,4 @@
1
+[DEFAULT]
2
+test_path=./tests
3
+top_dir=./
4
+

+ 0
- 4
.testr.conf View File

@@ -1,4 +0,0 @@
1
-[DEFAULT]
2
-test_command=OS_STDOUT_CAPTURE=1 OS_STDERR_CAPTURE=1 OS_TEST_TIMEOUT=60 ${PYTHON:-python} -m subunit.run discover -t ./ . $LISTOPT $IDOPTION
3
-test_id_option=--load-list $IDFILE
4
-test_list_option=--list

+ 1
- 1
requirements.txt View File

@@ -5,6 +5,6 @@ pbr>=2.0.0
5 5
 sphinx!=1.6.1,>=1.5.1
6 6
 sphinxcontrib-blockdiag
7 7
 openstackdocstheme>=1.17.0 # Apache-2.0
8
-testrepository>=0.0.18
8
+stestr>=2.0.0 # Apache-2.0
9 9
 testtools>=0.9.34
10 10
 doc8

+ 128
- 85
specs/keystone/rocky/define-default-roles.rst View File

@@ -71,15 +71,16 @@ use to adopt the proposed default roles in a future `community goal
71 71
 Default Roles
72 72
 -------------
73 73
 
74
-**reader**: It should only be used for read-only APIs and operations. Alternatively
75
-referred to as ``readonly`` or ``observer``, this role fills an extremely popular need from operators.
74
+**reader**: It should only be used for read-only APIs and operations.
75
+Alternatively referred to as ``readonly`` or ``observer``, this role fills
76
+an extremely popular need from operators.
76 77
 
77 78
 **member**: serves as the
78
-general purpose ‘do-er’ role. It introduces granularity between the administrator(s)
79
-and everyone else.
79
+general purpose ‘do-er’ role. It introduces granularity between
80
+the administrator(s) and everyone else.
80 81
 
81
-**admin**: This role will be only be considered appropriate for operations deemed too
82
-sensitive for anyone with a member role.
82
+**admin**: This role will be only be considered appropriate for operations
83
+deemed too sensitive for anyone with a member role.
83 84
 
84 85
 The desired outcome of implementing the roles above is that projects should
85 86
 start moving away from the practice of hardcoding operations to specific role
@@ -92,10 +93,10 @@ Scope Type (Refresher)
92 93
 **project-scope**: Project-scope relates to authorization for operating in a
93 94
 specific tenancy of the cloud.
94 95
 
95
-**system-scope**: System-scope relates to authorization for operating with APIs that
96
-do not map nicely to the concept of Project scope. It is **not** meant to cover *all*
97
-APIs across a deployment. More information about system-scope can be found in the `specification
98
-<http://specs.openstack.org/openstack/keystone-specs/specs/keystone/queens/system-scope.html>`_,
96
+**system-scope**: System-scope relates to authorization for operating with APIs
97
+that do not map nicely to the concept of Project scope. It is **not** meant to
98
+cover *all* APIs across a deployment. More information about system-scope can
99
+be found in the `specification <http://specs.openstack.org/openstack/keystone-specs/specs/keystone/queens/system-scope.html>`_,
99 100
 along with relevant historical context justifying the `need for system-scope
100 101
 <https://bugs.launchpad.net/keystone/+bug/968696>`_.
101 102
 
@@ -103,62 +104,97 @@ Examples
103 104
 --------
104 105
 
105 106
 `reader:`
106
-An example project-scoped application of this role would be listing project tags (``identity:get_project_tags``).
107
-An example system-scoped application of this role would be listing service endpoints
108
-(``identity:list_endpoints``).
107
+An example project-scoped application of this role would be listing project
108
+tags (``identity:get_project_tags``).
109
+An example system-scoped application of this role would be listing service
110
+endpoints (``identity:list_endpoints``).
109 111
 
110 112
 `member:`
111
-An example project-scoped application of this role would be creating a project tag (``identity:update_project_tags``).
113
+An example project-scoped application of this role would be creating a project
114
+tag (``identity:update_project_tags``).
112 115
 An example system-scope application of this role would be updating an endpoint
113 116
 (``identity:update_endpoint``).
114 117
 
115 118
 `admin:`
116
-An example project-scoped administrator operation would be deleting project tags (``identity:delete_project_tags``).
117
-An example system-scoped administrator operation would be creating an endpoint for a service
118
-(``identity:create_endpoint``) or listing migrations (``os_compute_api:os-migrations``).
119
-
120
-
121
-The following table is neither a final nor a comprehensive list of all possible rules/policies.
122
-It serves merely as a snippet of existing rules to showcase how policies, scope, and the new
123
-default roles can work together to provide a richer policy experience.
124
-
125
-+-------------+------------------------------+---------------------------------+---------------------------------+
126
-|             | reader                       | member                          | admin                           |
127
-+=============+==============================+=================================+=================================+
128
-| **Project** | * identity:list_project_tags | * identity:list_project_tags    | * identity:list_project_tags    |
129
-|             | * identity:get_project_tag   | * identity:get_project_tag      | * identity:get_project_tag      |
130
-|             |                              | * identity:update_project_tags  | * identity:update_project_tags  |
131
-|             |                              |                                 | * identity:create_project_tag   |
132
-|             |                              |                                 | * identity:delete_project_tags  |
133
-+-------------+------------------------------+---------------------------------+---------------------------------+
134
-| **System**  | * identity:list_endpoints    | * identity:list_endpoints       | * identity:list_endpoints       |
135
-|             | * identity:get_endpoint      | * identity:get_endpoint         | * identity:get_endpoint         |
136
-|             |                              | * identity:update_endpoint      | * identity:update_endpoint      |
137
-|             |                              |                                 | * identity:create_endpoint      |
138
-|             |                              |                                 | * os_compute_api:os-hypervisors |
139
-|             |                              |                                 | * os_compute_api:os-migrations  |
140
-+-------------+------------------------------+---------------------------------+---------------------------------+
119
+An example project-scoped administrator operation would be deleting project
120
+tags (``identity:delete_project_tags``).
121
+An example system-scoped administrator operation would be creating an endpoint
122
+for a service (``identity:create_endpoint``) or
123
+listing migrations (``os_compute_api:os-migrations``).
141 124
 
142 125
 
126
+The following is neither a final nor a comprehensive list of all possible
127
+rules/policies. It serves merely as a snippet of existing rules to showcase how
128
+policies, scope, and the new default roles can work together to provide a
129
+richer policy experience.
130
+
131
+Project Reader
132
+~~~~~~~~~~~~~~
133
+
134
+* ``identity:list_project_tags``
135
+* ``identity:get_project_tag``
136
+
137
+Project Member
138
+~~~~~~~~~~~~~~
139
+
140
+* ``identity:list_project_tags``
141
+* ``identity:get_project_tag``
142
+* ``identity:update_project_tags``
143
+
144
+Project Admin
145
+~~~~~~~~~~~~~
146
+
147
+* ``identity:list_project_tags``
148
+* ``identity:get_project_tag``
149
+* ``identity:update_project_tags``
150
+* ``identity:create_project_tags``
151
+* ``identity:delete_project_tags``
152
+
153
+System Reader
154
+~~~~~~~~~~~~~
155
+
156
+* ``identity:list_endpoints``
157
+* ``identity:get_endpoint``
158
+
159
+System Member
160
+~~~~~~~~~~~~~
161
+
162
+* ``identity:list_endpoints``
163
+* ``identity:get_endpoint``
164
+* ``identity:update_endpoints``
165
+
166
+System Admin
167
+~~~~~~~~~~~~
168
+
169
+* ``identity:list_endpoints``
170
+* ``identity:get_endpoint``
171
+* ``identity:update_endpoints``
172
+* ``identity:create_endpoints``
173
+* ``os-compute-api:os-hypervisors``
174
+* ``os-compute-api:os-migrations``
175
+
143 176
 Example snippets of various policy files, or rendered snippets, could look like
144 177
 the following.
145 178
 
146 179
 .. note::
147 180
 
148
-  The default roles discussed will be created by Keystone, during the bootstrap process, using `implied roles
181
+  The default roles discussed will be created by Keystone, during the bootstrap
182
+  process, using `implied roles
149 183
   <https://docs.openstack.org/python-openstackclient/latest/cli/command-objects/implied_role.html>`_.
150
-  As indicated in the above table, having ``admin`` role implies a user also has the same rights as
151
-  the ``member`` role. Therefore this user will also has the same rights as the ``reader`` role as
152
-  ``member`` implies ``reader``.
184
+  As indicated in the above table, having ``admin`` role implies a user also
185
+  has the same rights as the ``member`` role. Therefore this user will also has
186
+  the same rights as the ``reader`` role as ``member`` implies ``reader``.
153 187
 
154
-  This keeps policy files clean. For example:
188
+  This keeps policy files clean. For example, the following are equivalent as a
189
+  result of implied roles:
155 190
 
156
-  "identity:list_endpoints": "role:reader OR role:member OR role:admin" is equivalent to
157
-  "identity:list_endpoints": "role:reader" as a result of the implied roles chain.
191
+  "identity:list_endpoints": "role:reader OR role:member OR role:admin"
192
+  "identity:list_endpoints": "role:reader"
158 193
 
159
-   The chain of implied roles will be documented alongside of the `policy-in-code defaults
160
-   <https://github.com/openstack/keystone/blob/master/keystone/common/policies/base.py>`_ in addition to
161
-   general Keystone documentation updates noting as much.
194
+   The chain of implied roles will be documented alongside of the
195
+   `policy-in-code defaults
196
+   <https://github.com/openstack/keystone/blob/master/keystone/common/policies/base.py>`_
197
+   in addition to general Keystone documentation updates noting as much.
162 198
 
163 199
 ::
164 200
 
@@ -189,53 +225,60 @@ Let's assume the following role assignment exist:
189 225
 
190 226
 Given the above assignments and policies, the following would be possible:
191 227
 
192
-**Alice** can list or retrieve specific endpoints. Alice cannot do any project specific
193
-operations since her authorization is limited to the deployment system.
228
+**Alice** can list or retrieve specific endpoints. Alice cannot do any project
229
+specific operations since her authorization is limited to the deployment
230
+system.
194 231
 
195
-**Bob** can retrieve specific endpoints, list them, and update them. He cannot create new
196
-endpoints, or delete existing ones. Bob cannot do any project specific operations because his
197
-authorization is limited to the deployment system.
232
+**Bob** can retrieve specific endpoints, list them, and update them. He cannot
233
+create new endpoints, or delete existing ones. Bob cannot do any project
234
+specific operations because his authorization is limited to the deployment
235
+system.
198 236
 
199
-**Charlie** can retrieve specific endpoints, list, as well as create them. Additionally, Charlie
200
-can list information on migrations as well as hypervisors. He cannot perform any project specific
201
-operations because his authorization is limited to the deployment system.
237
+**Charlie** can retrieve specific endpoints, list, as well as create them.
238
+Additionally, Charlie can list information on migrations as well as
239
+hypervisors. He cannot perform any project specific operations because his
240
+authorization is limited to the deployment system.
202 241
 
203
-**Qiana** can list all tags and get details about a specific tag within Project Alpha. She may not
204
-perform system specific policies because her authorization is on a single project.
242
+**Qiana** can list all tags and get details about a specific tag within Project
243
+Alpha. She may not perform system specific policies because her authorization
244
+is on a single project.
205 245
 
206
-**Rebecca** can list all tags, get details about a specific tag, and update a tag within Project
207
-Alpha. She cannot perform any system specific policies because her authorization is on a single
208
-project.
246
+**Rebecca** can list all tags, get details about a specific tag, and update a
247
+tag within Project Alpha. She cannot perform any system specific policies
248
+because her authorization is on a single project.
209 249
 
210
-**Steve** can list all tags, create new tags, get details about a specific tag, update a tag, and
211
-delete tags within Project Alpha. He cannot perform any system specific policies because his
212
-authorization is on a single project.
250
+**Steve** can list all tags, create new tags, get details about a specific tag,
251
+update a tag, and delete tags within Project Alpha. He cannot perform any
252
+system specific policies because his authorization is on a single project.
213 253
 
214 254
 Risk Mitigation
215 255
 ---------------
216 256
 
217
-**Scenario One -- A role serving the purposes described in this spec exists under another name**:
218
-Let us assume that Deployment A already has ``Role X`` which serves the purpose of the proposed here as
219
-the ``reader`` role. In this instance, it is reasonable to assume that operators may have custom policy
220
-work in place and do not want to port immediately.
257
+**Scenario One -- A role serving the purposes described in this spec exists
258
+under another name**: Let us assume that Deployment A already has ``Role X``
259
+which serves the purpose of the proposed here as the ``reader`` role. In this
260
+instance, it is reasonable to assume that operators may have custom policy work
261
+in place and do not want to port immediately.
221 262
 
222
-This issue may be mitigated through the use of implied roles. Operators need simply to ensure that
223
-``reader`` implies ``Role X``. Please review the documentation on `implied roles
224
-<https://docs.openstack.org/python-openstackclient/latest/cli/command-objects/implied_role.html>`_. for
225
-specific instructions on how make one role imply another.
263
+This issue may be mitigated through the use of implied roles. Operators need
264
+simply to ensure that ``reader`` implies ``Role X``. Please review the
265
+documentation on `implied roles
266
+<https://docs.openstack.org/python-openstackclient/latest/cli/command-objects/implied_role.html>`_.
267
+for specific instructions on how make one role imply another.
226 268
 
227
-**Scenario Two -- An existing ``reader``, ``member``, or ``admin`` role already exists**: Let us assume
228
-that Deployment B already has a ``member`` role. Keystone will not attempt to overwrite any existing roles
229
-that have been populated. It will instead note that a role with the name ``member`` already exists in log
230
-output.
269
+**Scenario Two -- An existing ``reader``, ``member``, or ``admin`` role already
270
+exists**: Let us assume that Deployment B already has a ``member`` role.
271
+Keystone will not attempt to overwrite any existing roles that have been
272
+populated. It will instead note that a role with the name ``member`` already
273
+exists in log output.
231 274
 
232 275
 Alternatives
233 276
 ------------
234 277
 
235
-reader/writer/admin vs reader/member/admin. There was much debate regarding the naming
236
-conventions for these roles. We have opted to use `reader`, `member`, and `admin` as we
237
-believe they most accurately describe their purpose when the context of OpenStack is taken
238
-into consideration.
278
+reader/writer/admin vs reader/member/admin. There was much debate regarding the
279
+naming conventions for these roles. We have opted to use `reader`, `member`,
280
+and `admin` as we believe they most accurately describe their purpose when the
281
+context of OpenStack is taken into consideration.
239 282
 
240 283
 Implementation
241 284
 ==============
@@ -258,8 +301,8 @@ Work Items
258 301
 * Implement scope_types for all policies in Keystone
259 302
 * Remove @protected decorator
260 303
 * Document how operators may generate policy files with service specific roles
261
-* Prepare Proof-of-Concept to demo and facilitate acceptance of an OpenStack Community Goal
262
-  to promote default roles across the other services.
304
+* Prepare Proof-of-Concept to demo and facilitate acceptance of an OpenStack
305
+  Community Goal to promote default roles across the other services.
263 306
 
264 307
 Dependencies
265 308
 ============
@@ -297,6 +340,6 @@ Resources
297 340
 
298 341
 .. note::
299 342
 
300
-  This work is licensed under a Creative Commons Attribution 3.0 Unported License.
301
-  http://creativecommons.org/licenses/by/3.0/legalcode
343
+  This work is licensed under a Creative Commons Attribution 3.0 Unported
344
+  License.  http://creativecommons.org/licenses/by/3.0/legalcode
302 345
 

+ 1
- 1
tox.ini View File

@@ -9,7 +9,7 @@ setenv = VIRTUAL_ENV={envdir}
9 9
 install_command = pip install -U {opts} {packages}
10 10
 deps = -r{toxinidir}/requirements.txt
11 11
 commands =
12
-    python setup.py testr --slowest --testr-args='{posargs}'
12
+    stestr run --slowest {posargs}
13 13
     doc8 specs/
14 14
 
15 15
 [testenv:venv]

Loading…
Cancel
Save