openstack
/
keystone
Code Issues Proposed changes

Remove pbr warnerrors in favor of sphinx check 

This change removes the unused "warnerrors" setting that
was part of [pbr] which was replaced by "warning-is-error"
in sphinx 1.5 and above[0]. This also fixes any warnings
and errors that came up when running `tox -edocs` using
this new feature:

 - Invalid code example highlighting
 - Redundant loading of todo extension

[0] http://lists.openstack.org/pipermail/openstack-dev/2017-March/113085.html

Change-Id: I9a8789b448ffa199b4539f57e692bac251d75036
This commit is contained in:
Gage Hugo 2017-03-01 09:42:28 -06:00
parent f89335b09d
commit 32da690e50
6 changed files with 73 additions and 91 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

1
doc/source/conf.py
View File

@ -48,7 +48,6 @@ sys.path.insert(0, os.path.abspath('./'))
# extensions coming with Sphinx (named 'sphinx.ext.*') or your custom
# ones.
extensions = ['sphinx.ext.autodoc',
'sphinx.ext.todo',
'sphinx.ext.coverage',
'sphinx.ext.viewcode',
'oslo_config.sphinxconfiggen',

143
doc/source/federation/mapping_combinations.rst
View File

@ -43,7 +43,7 @@ Definitions
A mapping looks as follows:
.. code-block:: javascript
.. code-block:: none
{
"rules": [
@ -114,7 +114,7 @@ After the rule is found using the rule's conditions and a list of direct mapping
stored, keystone begins processing the rule's `local` property. Each object in
the `local` property is collapsed into a single JSON object. For example:
.. code-block:: javascript
.. code-block:: none
{
"local": [
@ -129,7 +129,7 @@ the `local` property is collapsed into a single JSON object. For example:
becomes:
.. code-block:: javascript
.. code-block:: none
{
"local": {
@ -140,7 +140,7 @@ becomes:
when the same property exists in the local multiple times the first occurrence wins:
.. code-block:: javascript
.. code-block:: none
{
"local": [
@ -158,7 +158,7 @@ when the same property exists in the local multiple times the first occurrence w
becomes:
.. code-block:: javascript
.. code-block:: none
{
"local": {
@ -230,7 +230,7 @@ The following are all examples of mapping rule types.
empty condition
~~~~~~~~~~~~~~~
.. code-block:: javascript
.. code-block:: json
{
"rules": [
@ -288,7 +288,7 @@ other conditions
In ``<other_condition>`` shown below, please supply one of the following:
``any_one_of``, or ``not_any_of``.
.. code-block:: javascript
.. code-block:: json
{
"rules": [
@ -321,7 +321,7 @@ In ``<other_condition>`` shown below, please supply one of the following:
In ``<other_condition>`` shown below, please supply one of the following:
``blacklist``, or ``whitelist``.
.. code-block:: javascript
.. code-block:: json
{
"rules": [
@ -362,7 +362,7 @@ In ``<other_condition>`` shown below, please supply one of the following:
Group ids and names can be provided in the local section:
.. code-block:: javascript
.. code-block:: json
{
"local": [
@ -374,7 +374,7 @@ Group ids and names can be provided in the local section:
]
}
.. code-block:: javascript
.. code-block:: json
{
"local": [
@ -389,7 +389,7 @@ Group ids and names can be provided in the local section:
]
}
.. code-block:: javascript
.. code-block:: json
{
"local": [
@ -410,7 +410,7 @@ Output
If a mapping is valid you will receive the following output:
.. code-block:: javascript
.. code-block:: none
{
"group_ids": "[<group-ids>]",
@ -473,7 +473,7 @@ Regular Expressions
Regular expressions can be used in a mapping by specifying the ``regex`` key, and
setting it to ``true``.
.. code-block:: javascript
.. code-block:: json
{
"rules": [
@ -517,7 +517,7 @@ but cannot be repeated within the same condition. ``any_one_of`` and
``not_any_of`` are mutually exclusive within a condition's scope. So are
``whitelist`` and ``blacklist``.
.. code-block:: javascript
.. code-block:: json
{
"rules": [
@ -560,7 +560,7 @@ As before group names and users can also be provided in the local section.
This allows any user with the following claim information to be mapped to
group with id 0cd5e9.
.. code-block:: javascript
.. code-block:: json
{"UserName":"<any_name>@yeah.com"}
{"cn=IBM_USA_Lab":"<any_name>@yeah.com"}
@ -577,7 +577,7 @@ Multiple Rules
Multiple rules can also be utilized in a mapping.
.. code-block:: javascript
.. code-block:: json
{
"rules": [
@ -657,68 +657,55 @@ user and another rule for just groups. Below is rules example repeated but with
global username mapping.
.. code-block:: javascript
.. code-block:: json
{
"rules": [
{
"local": [
"user": {
"id": "{0}"
}
],
"remote": [
{
"type": "UserType"
}
]
},
{
"local": [
{
"group": {
"name": "non-contractors",
"domain": {
"id": "abc1234"
}
}
}
],
"remote": [
{
"type": "orgPersonType",
"not_any_of": [
"Contractor",
"SubContractor"
]
}
]
},
{
"local": [
{
"group": {
"name": "contractors",
"domain": {
"id": "abc1234"
}
}
}
],
"remote": [
{
"type": "orgPersonType",
"any_one_of": [
"Contractor",
"SubContractor"
]
}
]
}
]
{
"rules": [{
"local": [{
"user": {
"id": "{0}"
}
}],
"remote": [{
"type": "UserType"
}]
},
{
"local": [{
"group": {
"name": "non-contractors",
"domain": {
"id": "abc1234"
}
}
}],
"remote": [{
"type": "orgPersonType",
"not_any_of": [
"Contractor",
"SubContractor"
]
}]
},
{
"local": [{
"group": {
"name": "contractors",
"domain": {
"id": "abc1234"
}
}
}],
"remote": [{
"type": "orgPersonType",
"any_one_of": [
"Contractor",
"SubContractor"
]
}]
}]
}
Auto-Provisioning
-----------------
@ -729,7 +716,7 @@ ultimately make decisions on.
For example, consider the following mapping:
.. code-block:: javascript
.. code-block:: json
{
"rules": [
@ -818,7 +805,7 @@ user having direct role assignments on the projects in the ``projects`` list.
The following example contains ``local`` rules comprised of both ``projects``
and ``groups``, which allow for direct role assignments and group memberships.
.. code-block:: javascript
.. code-block:: json
{
"rules": [
@ -895,7 +882,7 @@ names we have in the Identity Provider. It will map any user with the name
``user1`` or ``admin`` in the ``openstack_user`` attribute and
``openstack_domain`` attribute ``default`` to a group with id ``abc1234``.
.. code-block:: javascript
.. code-block:: json
{
"rules": [

2
doc/source/federation/mellon.rst
View File

@ -40,7 +40,7 @@ Add this *WSGIScriptAlias* directive to your public vhost configuration::
Make sure the *wsgi-keystone.conf* contains a *<Location>* directive for the Mellon module and
a *<Location>* directive for each identity provider
.. code-block:: xml
.. code-block:: none
<Location /v3>
MellonEnable "info"

2
doc/source/federation/openidc.rst
View File

@ -42,7 +42,7 @@ Enable the auth_openidc module:
In the keystone vhost file, locate the virtual host entry and add the following
entries for OpenID Connect:
.. code-block:: xml
.. code-block:: none
<VirtualHost *:5000>

8
doc/source/federation/websso.rst
View File

@ -49,7 +49,7 @@ is configured in keystone.
If `mod_shib` is used, then use the following as an example:
.. code-block:: xml
.. code-block:: none
<VirtualHost *:5000>
@ -70,7 +70,7 @@ If `mod_shib` is used, then use the following as an example:
If `mod_auth_openidc` is used, then use the following as an example:
.. code-block:: xml
.. code-block:: none
<VirtualHost *:5000>
@ -93,7 +93,7 @@ If `mod_auth_openidc` is used, then use the following as an example:
If `mod_auth_kerb` is used, then use the following as an example:
.. code-block:: xml
.. code-block:: none
<VirtualHost *:5000>
@ -119,7 +119,7 @@ If `mod_auth_kerb` is used, then use the following as an example:
If `mod_auth_mellon` is used, then use the following as an example:
.. code-block:: xml
.. code-block:: none
<VirtualHost *:5000>

8
setup.cfg
View File

@ -48,6 +48,7 @@ tag_svn_revision = 0
all_files = 1
build-dir = doc/build
source-dir = doc/source
warning-is-error = 1
[compile_catalog]
directory = keystone/locale
@ -66,17 +67,12 @@ copyright_holder = OpenStack Foundation
msgid_bugs_address = https://bugs.launchpad.net/keystone
[pbr]
# NOTE(jamielennox): warnerrors was not warning as it should and will be fixed
# in an upcoming PBR release, which means it may suddenly start warning and
# failing builds again. It's disabled until the release happens. Info:
# http://lists.openstack.org/pipermail/openstack-dev/2016-June/097849.html
#warnerrors = True
autodoc_tree_index_modules = True
# NOTE(gagehugo): building docs with autodoc_tree_index_modules set to True
# causes warnings when creating api docs with keystone_tempest_plugin and
# these issues seem to be related to tempest/oslo_config rather than
# keystone.
autodoc_tree_excludes = keystone_tempest_plugin
autodoc_tree_excludes = keystone_tempest_plugin setup.py
[entry_points]
console_scripts =