From 4fe55f0e826da2e868d1147b02af5ad1f9a8498d Mon Sep 17 00:00:00 2001 From: Vu Cong Tuan Date: Tue, 10 Jul 2018 18:26:00 +0700 Subject: [PATCH] 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 --- .gitignore | 2 +- .stestr.conf | 4 + .testr.conf | 4 - requirements.txt | 2 +- specs/keystone/rocky/define-default-roles.rst | 207 +++++++++++------- tox.ini | 2 +- 6 files changed, 132 insertions(+), 89 deletions(-) create mode 100644 .stestr.conf delete mode 100644 .testr.conf diff --git a/.gitignore b/.gitignore index 6efcb005..cb32b7df 100644 --- a/.gitignore +++ b/.gitignore @@ -7,4 +7,4 @@ build *.swp *.swo *.pyc -.testrepository +.stestr/ diff --git a/.stestr.conf b/.stestr.conf new file mode 100644 index 00000000..dcdf16e8 --- /dev/null +++ b/.stestr.conf @@ -0,0 +1,4 @@ +[DEFAULT] +test_path=./tests +top_dir=./ + diff --git a/.testr.conf b/.testr.conf deleted file mode 100644 index 1641f86e..00000000 --- a/.testr.conf +++ /dev/null @@ -1,4 +0,0 @@ -[DEFAULT] -test_command=OS_STDOUT_CAPTURE=1 OS_STDERR_CAPTURE=1 OS_TEST_TIMEOUT=60 ${PYTHON:-python} -m subunit.run discover -t ./ . $LISTOPT $IDOPTION -test_id_option=--load-list $IDFILE -test_list_option=--list diff --git a/requirements.txt b/requirements.txt index 5f850d35..5fe951b7 100644 --- a/requirements.txt +++ b/requirements.txt @@ -5,6 +5,6 @@ pbr>=2.0.0 sphinx!=1.6.1,>=1.5.1 sphinxcontrib-blockdiag openstackdocstheme>=1.17.0 # Apache-2.0 -testrepository>=0.0.18 +stestr>=2.0.0 # Apache-2.0 testtools>=0.9.34 doc8 diff --git a/specs/keystone/rocky/define-default-roles.rst b/specs/keystone/rocky/define-default-roles.rst index 7c00a028..c57dab85 100644 --- a/specs/keystone/rocky/define-default-roles.rst +++ b/specs/keystone/rocky/define-default-roles.rst @@ -71,15 +71,16 @@ use to adopt the proposed default roles in a future `community goal Default Roles ------------- -**reader**: It should only be used for read-only APIs and operations. Alternatively -referred to as ``readonly`` or ``observer``, this role fills an extremely popular need from operators. +**reader**: It should only be used for read-only APIs and operations. +Alternatively referred to as ``readonly`` or ``observer``, this role fills +an extremely popular need from operators. **member**: serves as the -general purpose ‘do-er’ role. It introduces granularity between the administrator(s) -and everyone else. +general purpose ‘do-er’ role. It introduces granularity between +the administrator(s) and everyone else. -**admin**: This role will be only be considered appropriate for operations deemed too -sensitive for anyone with a member role. +**admin**: This role will be only be considered appropriate for operations +deemed too sensitive for anyone with a member role. The desired outcome of implementing the roles above is that projects should start moving away from the practice of hardcoding operations to specific role @@ -92,10 +93,10 @@ Scope Type (Refresher) **project-scope**: Project-scope relates to authorization for operating in a specific tenancy of the cloud. -**system-scope**: System-scope relates to authorization for operating with APIs that -do not map nicely to the concept of Project scope. It is **not** meant to cover *all* -APIs across a deployment. More information about system-scope can be found in the `specification -`_, +**system-scope**: System-scope relates to authorization for operating with APIs +that do not map nicely to the concept of Project scope. It is **not** meant to +cover *all* APIs across a deployment. More information about system-scope can +be found in the `specification `_, along with relevant historical context justifying the `need for system-scope `_. @@ -103,62 +104,97 @@ Examples -------- `reader:` -An example project-scoped application of this role would be listing project tags (``identity:get_project_tags``). -An example system-scoped application of this role would be listing service endpoints -(``identity:list_endpoints``). +An example project-scoped application of this role would be listing project +tags (``identity:get_project_tags``). +An example system-scoped application of this role would be listing service +endpoints (``identity:list_endpoints``). `member:` -An example project-scoped application of this role would be creating a project tag (``identity:update_project_tags``). +An example project-scoped application of this role would be creating a project +tag (``identity:update_project_tags``). An example system-scope application of this role would be updating an endpoint (``identity:update_endpoint``). `admin:` -An example project-scoped administrator operation would be deleting project tags (``identity:delete_project_tags``). -An example system-scoped administrator operation would be creating an endpoint for a service -(``identity:create_endpoint``) or listing migrations (``os_compute_api:os-migrations``). +An example project-scoped administrator operation would be deleting project +tags (``identity:delete_project_tags``). +An example system-scoped administrator operation would be creating an endpoint +for a service (``identity:create_endpoint``) or +listing migrations (``os_compute_api:os-migrations``). -The following table is neither a final nor a comprehensive list of all possible rules/policies. -It serves merely as a snippet of existing rules to showcase how policies, scope, and the new -default roles can work together to provide a richer policy experience. +The following is neither a final nor a comprehensive list of all possible +rules/policies. It serves merely as a snippet of existing rules to showcase how +policies, scope, and the new default roles can work together to provide a +richer policy experience. -+-------------+------------------------------+---------------------------------+---------------------------------+ -| | reader | member | admin | -+=============+==============================+=================================+=================================+ -| **Project** | * identity:list_project_tags | * identity:list_project_tags | * identity:list_project_tags | -| | * identity:get_project_tag | * identity:get_project_tag | * identity:get_project_tag | -| | | * identity:update_project_tags | * identity:update_project_tags | -| | | | * identity:create_project_tag | -| | | | * identity:delete_project_tags | -+-------------+------------------------------+---------------------------------+---------------------------------+ -| **System** | * identity:list_endpoints | * identity:list_endpoints | * identity:list_endpoints | -| | * identity:get_endpoint | * identity:get_endpoint | * identity:get_endpoint | -| | | * identity:update_endpoint | * identity:update_endpoint | -| | | | * identity:create_endpoint | -| | | | * os_compute_api:os-hypervisors | -| | | | * os_compute_api:os-migrations | -+-------------+------------------------------+---------------------------------+---------------------------------+ +Project Reader +~~~~~~~~~~~~~~ +* ``identity:list_project_tags`` +* ``identity:get_project_tag`` + +Project Member +~~~~~~~~~~~~~~ + +* ``identity:list_project_tags`` +* ``identity:get_project_tag`` +* ``identity:update_project_tags`` + +Project Admin +~~~~~~~~~~~~~ + +* ``identity:list_project_tags`` +* ``identity:get_project_tag`` +* ``identity:update_project_tags`` +* ``identity:create_project_tags`` +* ``identity:delete_project_tags`` + +System Reader +~~~~~~~~~~~~~ + +* ``identity:list_endpoints`` +* ``identity:get_endpoint`` + +System Member +~~~~~~~~~~~~~ + +* ``identity:list_endpoints`` +* ``identity:get_endpoint`` +* ``identity:update_endpoints`` + +System Admin +~~~~~~~~~~~~ + +* ``identity:list_endpoints`` +* ``identity:get_endpoint`` +* ``identity:update_endpoints`` +* ``identity:create_endpoints`` +* ``os-compute-api:os-hypervisors`` +* ``os-compute-api:os-migrations`` Example snippets of various policy files, or rendered snippets, could look like the following. .. note:: - The default roles discussed will be created by Keystone, during the bootstrap process, using `implied roles + The default roles discussed will be created by Keystone, during the bootstrap + process, using `implied roles `_. - As indicated in the above table, having ``admin`` role implies a user also has the same rights as - the ``member`` role. Therefore this user will also has the same rights as the ``reader`` role as - ``member`` implies ``reader``. + As indicated in the above table, having ``admin`` role implies a user also + has the same rights as the ``member`` role. Therefore this user will also has + the same rights as the ``reader`` role as ``member`` implies ``reader``. - This keeps policy files clean. For example: + This keeps policy files clean. For example, the following are equivalent as a + result of implied roles: - "identity:list_endpoints": "role:reader OR role:member OR role:admin" is equivalent to - "identity:list_endpoints": "role:reader" as a result of the implied roles chain. + "identity:list_endpoints": "role:reader OR role:member OR role:admin" + "identity:list_endpoints": "role:reader" - The chain of implied roles will be documented alongside of the `policy-in-code defaults - `_ in addition to - general Keystone documentation updates noting as much. + The chain of implied roles will be documented alongside of the + `policy-in-code defaults + `_ + in addition to general Keystone documentation updates noting as much. :: @@ -189,53 +225,60 @@ Let's assume the following role assignment exist: Given the above assignments and policies, the following would be possible: -**Alice** can list or retrieve specific endpoints. Alice cannot do any project specific -operations since her authorization is limited to the deployment system. +**Alice** can list or retrieve specific endpoints. Alice cannot do any project +specific operations since her authorization is limited to the deployment +system. -**Bob** can retrieve specific endpoints, list them, and update them. He cannot create new -endpoints, or delete existing ones. Bob cannot do any project specific operations because his +**Bob** can retrieve specific endpoints, list them, and update them. He cannot +create new endpoints, or delete existing ones. Bob cannot do any project +specific operations because his authorization is limited to the deployment +system. + +**Charlie** can retrieve specific endpoints, list, as well as create them. +Additionally, Charlie can list information on migrations as well as +hypervisors. He cannot perform any project specific operations because his authorization is limited to the deployment system. -**Charlie** can retrieve specific endpoints, list, as well as create them. Additionally, Charlie -can list information on migrations as well as hypervisors. He cannot perform any project specific -operations because his authorization is limited to the deployment system. +**Qiana** can list all tags and get details about a specific tag within Project +Alpha. She may not perform system specific policies because her authorization +is on a single project. -**Qiana** can list all tags and get details about a specific tag within Project Alpha. She may not -perform system specific policies because her authorization is on a single project. +**Rebecca** can list all tags, get details about a specific tag, and update a +tag within Project Alpha. She cannot perform any system specific policies +because her authorization is on a single project. -**Rebecca** can list all tags, get details about a specific tag, and update a tag within Project -Alpha. She cannot perform any system specific policies because her authorization is on a single -project. - -**Steve** can list all tags, create new tags, get details about a specific tag, update a tag, and -delete tags within Project Alpha. He cannot perform any system specific policies because his -authorization is on a single project. +**Steve** can list all tags, create new tags, get details about a specific tag, +update a tag, and delete tags within Project Alpha. He cannot perform any +system specific policies because his authorization is on a single project. Risk Mitigation --------------- -**Scenario One -- A role serving the purposes described in this spec exists under another name**: -Let us assume that Deployment A already has ``Role X`` which serves the purpose of the proposed here as -the ``reader`` role. In this instance, it is reasonable to assume that operators may have custom policy -work in place and do not want to port immediately. +**Scenario One -- A role serving the purposes described in this spec exists +under another name**: Let us assume that Deployment A already has ``Role X`` +which serves the purpose of the proposed here as the ``reader`` role. In this +instance, it is reasonable to assume that operators may have custom policy work +in place and do not want to port immediately. -This issue may be mitigated through the use of implied roles. Operators need simply to ensure that -``reader`` implies ``Role X``. Please review the documentation on `implied roles -`_. for -specific instructions on how make one role imply another. +This issue may be mitigated through the use of implied roles. Operators need +simply to ensure that ``reader`` implies ``Role X``. Please review the +documentation on `implied roles +`_. +for specific instructions on how make one role imply another. -**Scenario Two -- An existing ``reader``, ``member``, or ``admin`` role already exists**: Let us assume -that Deployment B already has a ``member`` role. Keystone will not attempt to overwrite any existing roles -that have been populated. It will instead note that a role with the name ``member`` already exists in log -output. +**Scenario Two -- An existing ``reader``, ``member``, or ``admin`` role already +exists**: Let us assume that Deployment B already has a ``member`` role. +Keystone will not attempt to overwrite any existing roles that have been +populated. It will instead note that a role with the name ``member`` already +exists in log output. Alternatives ------------ -reader/writer/admin vs reader/member/admin. There was much debate regarding the naming -conventions for these roles. We have opted to use `reader`, `member`, and `admin` as we -believe they most accurately describe their purpose when the context of OpenStack is taken -into consideration. +reader/writer/admin vs reader/member/admin. There was much debate regarding the +naming conventions for these roles. We have opted to use `reader`, `member`, +and `admin` as we believe they most accurately describe their purpose when the +context of OpenStack is taken into consideration. Implementation ============== @@ -258,8 +301,8 @@ Work Items * Implement scope_types for all policies in Keystone * Remove @protected decorator * Document how operators may generate policy files with service specific roles -* Prepare Proof-of-Concept to demo and facilitate acceptance of an OpenStack Community Goal - to promote default roles across the other services. +* Prepare Proof-of-Concept to demo and facilitate acceptance of an OpenStack + Community Goal to promote default roles across the other services. Dependencies ============ @@ -297,6 +340,6 @@ Resources .. note:: - This work is licensed under a Creative Commons Attribution 3.0 Unported License. - http://creativecommons.org/licenses/by/3.0/legalcode + This work is licensed under a Creative Commons Attribution 3.0 Unported + License. http://creativecommons.org/licenses/by/3.0/legalcode diff --git a/tox.ini b/tox.ini index 434f6c1d..4b4d1018 100644 --- a/tox.ini +++ b/tox.ini @@ -9,7 +9,7 @@ setenv = VIRTUAL_ENV={envdir} install_command = pip install -U {opts} {packages} deps = -r{toxinidir}/requirements.txt commands = - python setup.py testr --slowest --testr-args='{posargs}' + stestr run --slowest {posargs} doc8 specs/ [testenv:venv]