diff --git a/doc/source/conf.py b/doc/source/conf.py index 1704b932cf..755652e93f 100644 --- a/doc/source/conf.py +++ b/doc/source/conf.py @@ -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', diff --git a/doc/source/federation/mapping_combinations.rst b/doc/source/federation/mapping_combinations.rst index 6b2205e852..499a101015 100644 --- a/doc/source/federation/mapping_combinations.rst +++ b/doc/source/federation/mapping_combinations.rst @@ -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 ```` 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 ```` shown below, please supply one of the following: In ```` shown below, please supply one of the following: ``blacklist``, or ``whitelist``. -.. code-block:: javascript +.. code-block:: json { "rules": [ @@ -362,7 +362,7 @@ In ```` 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": "[]", @@ -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":"@yeah.com"} {"cn=IBM_USA_Lab":"@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": [ diff --git a/doc/source/federation/mellon.rst b/doc/source/federation/mellon.rst index 6b1a20a353..791accbb78 100644 --- a/doc/source/federation/mellon.rst +++ b/doc/source/federation/mellon.rst @@ -40,7 +40,7 @@ Add this *WSGIScriptAlias* directive to your public vhost configuration:: Make sure the *wsgi-keystone.conf* contains a ** directive for the Mellon module and a ** directive for each identity provider -.. code-block:: xml +.. code-block:: none MellonEnable "info" diff --git a/doc/source/federation/openidc.rst b/doc/source/federation/openidc.rst index 4d749c238d..5b78c13668 100644 --- a/doc/source/federation/openidc.rst +++ b/doc/source/federation/openidc.rst @@ -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 diff --git a/doc/source/federation/websso.rst b/doc/source/federation/websso.rst index 5836dfc85a..925c0723b1 100644 --- a/doc/source/federation/websso.rst +++ b/doc/source/federation/websso.rst @@ -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 @@ -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 @@ -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 @@ -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 diff --git a/setup.cfg b/setup.cfg index f1918e88b3..bcf4722c0d 100644 --- a/setup.cfg +++ b/setup.cfg @@ -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 =