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:
parent
f89335b09d
commit
32da690e50
|
@ -48,7 +48,6 @@ sys.path.insert(0, os.path.abspath('./'))
|
||||||
# extensions coming with Sphinx (named 'sphinx.ext.*') or your custom
|
# extensions coming with Sphinx (named 'sphinx.ext.*') or your custom
|
||||||
# ones.
|
# ones.
|
||||||
extensions = ['sphinx.ext.autodoc',
|
extensions = ['sphinx.ext.autodoc',
|
||||||
'sphinx.ext.todo',
|
|
||||||
'sphinx.ext.coverage',
|
'sphinx.ext.coverage',
|
||||||
'sphinx.ext.viewcode',
|
'sphinx.ext.viewcode',
|
||||||
'oslo_config.sphinxconfiggen',
|
'oslo_config.sphinxconfiggen',
|
||||||
|
|
|
@ -43,7 +43,7 @@ Definitions
|
||||||
|
|
||||||
A mapping looks as follows:
|
A mapping looks as follows:
|
||||||
|
|
||||||
.. code-block:: javascript
|
.. code-block:: none
|
||||||
|
|
||||||
{
|
{
|
||||||
"rules": [
|
"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
|
stored, keystone begins processing the rule's `local` property. Each object in
|
||||||
the `local` property is collapsed into a single JSON object. For example:
|
the `local` property is collapsed into a single JSON object. For example:
|
||||||
|
|
||||||
.. code-block:: javascript
|
.. code-block:: none
|
||||||
|
|
||||||
{
|
{
|
||||||
"local": [
|
"local": [
|
||||||
|
@ -129,7 +129,7 @@ the `local` property is collapsed into a single JSON object. For example:
|
||||||
|
|
||||||
becomes:
|
becomes:
|
||||||
|
|
||||||
.. code-block:: javascript
|
.. code-block:: none
|
||||||
|
|
||||||
{
|
{
|
||||||
"local": {
|
"local": {
|
||||||
|
@ -140,7 +140,7 @@ becomes:
|
||||||
|
|
||||||
when the same property exists in the local multiple times the first occurrence wins:
|
when the same property exists in the local multiple times the first occurrence wins:
|
||||||
|
|
||||||
.. code-block:: javascript
|
.. code-block:: none
|
||||||
|
|
||||||
{
|
{
|
||||||
"local": [
|
"local": [
|
||||||
|
@ -158,7 +158,7 @@ when the same property exists in the local multiple times the first occurrence w
|
||||||
|
|
||||||
becomes:
|
becomes:
|
||||||
|
|
||||||
.. code-block:: javascript
|
.. code-block:: none
|
||||||
|
|
||||||
{
|
{
|
||||||
"local": {
|
"local": {
|
||||||
|
@ -230,7 +230,7 @@ The following are all examples of mapping rule types.
|
||||||
empty condition
|
empty condition
|
||||||
~~~~~~~~~~~~~~~
|
~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
.. code-block:: javascript
|
.. code-block:: json
|
||||||
|
|
||||||
{
|
{
|
||||||
"rules": [
|
"rules": [
|
||||||
|
@ -288,7 +288,7 @@ other conditions
|
||||||
In ``<other_condition>`` shown below, please supply one of the following:
|
In ``<other_condition>`` shown below, please supply one of the following:
|
||||||
``any_one_of``, or ``not_any_of``.
|
``any_one_of``, or ``not_any_of``.
|
||||||
|
|
||||||
.. code-block:: javascript
|
.. code-block:: json
|
||||||
|
|
||||||
{
|
{
|
||||||
"rules": [
|
"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:
|
In ``<other_condition>`` shown below, please supply one of the following:
|
||||||
``blacklist``, or ``whitelist``.
|
``blacklist``, or ``whitelist``.
|
||||||
|
|
||||||
.. code-block:: javascript
|
.. code-block:: json
|
||||||
|
|
||||||
{
|
{
|
||||||
"rules": [
|
"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:
|
Group ids and names can be provided in the local section:
|
||||||
|
|
||||||
.. code-block:: javascript
|
.. code-block:: json
|
||||||
|
|
||||||
{
|
{
|
||||||
"local": [
|
"local": [
|
||||||
|
@ -374,7 +374,7 @@ Group ids and names can be provided in the local section:
|
||||||
]
|
]
|
||||||
}
|
}
|
||||||
|
|
||||||
.. code-block:: javascript
|
.. code-block:: json
|
||||||
|
|
||||||
{
|
{
|
||||||
"local": [
|
"local": [
|
||||||
|
@ -389,7 +389,7 @@ Group ids and names can be provided in the local section:
|
||||||
]
|
]
|
||||||
}
|
}
|
||||||
|
|
||||||
.. code-block:: javascript
|
.. code-block:: json
|
||||||
|
|
||||||
{
|
{
|
||||||
"local": [
|
"local": [
|
||||||
|
@ -410,7 +410,7 @@ Output
|
||||||
|
|
||||||
If a mapping is valid you will receive the following output:
|
If a mapping is valid you will receive the following output:
|
||||||
|
|
||||||
.. code-block:: javascript
|
.. code-block:: none
|
||||||
|
|
||||||
{
|
{
|
||||||
"group_ids": "[<group-ids>]",
|
"group_ids": "[<group-ids>]",
|
||||||
|
@ -473,7 +473,7 @@ Regular Expressions
|
||||||
Regular expressions can be used in a mapping by specifying the ``regex`` key, and
|
Regular expressions can be used in a mapping by specifying the ``regex`` key, and
|
||||||
setting it to ``true``.
|
setting it to ``true``.
|
||||||
|
|
||||||
.. code-block:: javascript
|
.. code-block:: json
|
||||||
|
|
||||||
{
|
{
|
||||||
"rules": [
|
"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
|
``not_any_of`` are mutually exclusive within a condition's scope. So are
|
||||||
``whitelist`` and ``blacklist``.
|
``whitelist`` and ``blacklist``.
|
||||||
|
|
||||||
.. code-block:: javascript
|
.. code-block:: json
|
||||||
|
|
||||||
{
|
{
|
||||||
"rules": [
|
"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
|
This allows any user with the following claim information to be mapped to
|
||||||
group with id 0cd5e9.
|
group with id 0cd5e9.
|
||||||
|
|
||||||
.. code-block:: javascript
|
.. code-block:: json
|
||||||
|
|
||||||
{"UserName":"<any_name>@yeah.com"}
|
{"UserName":"<any_name>@yeah.com"}
|
||||||
{"cn=IBM_USA_Lab":"<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.
|
Multiple rules can also be utilized in a mapping.
|
||||||
|
|
||||||
.. code-block:: javascript
|
.. code-block:: json
|
||||||
|
|
||||||
{
|
{
|
||||||
"rules": [
|
"rules": [
|
||||||
|
@ -657,67 +657,54 @@ user and another rule for just groups. Below is rules example repeated but with
|
||||||
global username mapping.
|
global username mapping.
|
||||||
|
|
||||||
|
|
||||||
.. code-block:: javascript
|
.. code-block:: json
|
||||||
|
|
||||||
{
|
{
|
||||||
"rules": [
|
"rules": [{
|
||||||
{
|
"local": [{
|
||||||
"local": [
|
|
||||||
"user": {
|
"user": {
|
||||||
"id": "{0}"
|
"id": "{0}"
|
||||||
}
|
}
|
||||||
],
|
}],
|
||||||
"remote": [
|
"remote": [{
|
||||||
{
|
|
||||||
"type": "UserType"
|
"type": "UserType"
|
||||||
}
|
}]
|
||||||
]
|
|
||||||
},
|
},
|
||||||
{
|
{
|
||||||
"local": [
|
"local": [{
|
||||||
{
|
|
||||||
"group": {
|
"group": {
|
||||||
"name": "non-contractors",
|
"name": "non-contractors",
|
||||||
"domain": {
|
"domain": {
|
||||||
"id": "abc1234"
|
"id": "abc1234"
|
||||||
}
|
}
|
||||||
}
|
}
|
||||||
}
|
}],
|
||||||
],
|
"remote": [{
|
||||||
"remote": [
|
|
||||||
{
|
|
||||||
"type": "orgPersonType",
|
"type": "orgPersonType",
|
||||||
"not_any_of": [
|
"not_any_of": [
|
||||||
"Contractor",
|
"Contractor",
|
||||||
"SubContractor"
|
"SubContractor"
|
||||||
]
|
]
|
||||||
}
|
}]
|
||||||
]
|
|
||||||
},
|
},
|
||||||
{
|
{
|
||||||
"local": [
|
"local": [{
|
||||||
{
|
|
||||||
"group": {
|
"group": {
|
||||||
"name": "contractors",
|
"name": "contractors",
|
||||||
"domain": {
|
"domain": {
|
||||||
"id": "abc1234"
|
"id": "abc1234"
|
||||||
}
|
}
|
||||||
}
|
}
|
||||||
}
|
}],
|
||||||
],
|
"remote": [{
|
||||||
"remote": [
|
|
||||||
{
|
|
||||||
"type": "orgPersonType",
|
"type": "orgPersonType",
|
||||||
"any_one_of": [
|
"any_one_of": [
|
||||||
"Contractor",
|
"Contractor",
|
||||||
"SubContractor"
|
"SubContractor"
|
||||||
]
|
]
|
||||||
|
}]
|
||||||
|
}]
|
||||||
}
|
}
|
||||||
]
|
|
||||||
}
|
|
||||||
]
|
|
||||||
}
|
|
||||||
|
|
||||||
|
|
||||||
Auto-Provisioning
|
Auto-Provisioning
|
||||||
-----------------
|
-----------------
|
||||||
|
@ -729,7 +716,7 @@ ultimately make decisions on.
|
||||||
|
|
||||||
For example, consider the following mapping:
|
For example, consider the following mapping:
|
||||||
|
|
||||||
.. code-block:: javascript
|
.. code-block:: json
|
||||||
|
|
||||||
{
|
{
|
||||||
"rules": [
|
"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``
|
The following example contains ``local`` rules comprised of both ``projects``
|
||||||
and ``groups``, which allow for direct role assignments and group memberships.
|
and ``groups``, which allow for direct role assignments and group memberships.
|
||||||
|
|
||||||
.. code-block:: javascript
|
.. code-block:: json
|
||||||
|
|
||||||
{
|
{
|
||||||
"rules": [
|
"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
|
``user1`` or ``admin`` in the ``openstack_user`` attribute and
|
||||||
``openstack_domain`` attribute ``default`` to a group with id ``abc1234``.
|
``openstack_domain`` attribute ``default`` to a group with id ``abc1234``.
|
||||||
|
|
||||||
.. code-block:: javascript
|
.. code-block:: json
|
||||||
|
|
||||||
{
|
{
|
||||||
"rules": [
|
"rules": [
|
||||||
|
|
|
@ -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
|
Make sure the *wsgi-keystone.conf* contains a *<Location>* directive for the Mellon module and
|
||||||
a *<Location>* directive for each identity provider
|
a *<Location>* directive for each identity provider
|
||||||
|
|
||||||
.. code-block:: xml
|
.. code-block:: none
|
||||||
|
|
||||||
<Location /v3>
|
<Location /v3>
|
||||||
MellonEnable "info"
|
MellonEnable "info"
|
||||||
|
|
|
@ -42,7 +42,7 @@ Enable the auth_openidc module:
|
||||||
In the keystone vhost file, locate the virtual host entry and add the following
|
In the keystone vhost file, locate the virtual host entry and add the following
|
||||||
entries for OpenID Connect:
|
entries for OpenID Connect:
|
||||||
|
|
||||||
.. code-block:: xml
|
.. code-block:: none
|
||||||
|
|
||||||
<VirtualHost *:5000>
|
<VirtualHost *:5000>
|
||||||
|
|
||||||
|
|
|
@ -49,7 +49,7 @@ is configured in keystone.
|
||||||
|
|
||||||
If `mod_shib` is used, then use the following as an example:
|
If `mod_shib` is used, then use the following as an example:
|
||||||
|
|
||||||
.. code-block:: xml
|
.. code-block:: none
|
||||||
|
|
||||||
<VirtualHost *:5000>
|
<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:
|
If `mod_auth_openidc` is used, then use the following as an example:
|
||||||
|
|
||||||
.. code-block:: xml
|
.. code-block:: none
|
||||||
|
|
||||||
<VirtualHost *:5000>
|
<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:
|
If `mod_auth_kerb` is used, then use the following as an example:
|
||||||
|
|
||||||
.. code-block:: xml
|
.. code-block:: none
|
||||||
|
|
||||||
<VirtualHost *:5000>
|
<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:
|
If `mod_auth_mellon` is used, then use the following as an example:
|
||||||
|
|
||||||
.. code-block:: xml
|
.. code-block:: none
|
||||||
|
|
||||||
<VirtualHost *:5000>
|
<VirtualHost *:5000>
|
||||||
|
|
||||||
|
|
|
@ -48,6 +48,7 @@ tag_svn_revision = 0
|
||||||
all_files = 1
|
all_files = 1
|
||||||
build-dir = doc/build
|
build-dir = doc/build
|
||||||
source-dir = doc/source
|
source-dir = doc/source
|
||||||
|
warning-is-error = 1
|
||||||
|
|
||||||
[compile_catalog]
|
[compile_catalog]
|
||||||
directory = keystone/locale
|
directory = keystone/locale
|
||||||
|
@ -66,17 +67,12 @@ copyright_holder = OpenStack Foundation
|
||||||
msgid_bugs_address = https://bugs.launchpad.net/keystone
|
msgid_bugs_address = https://bugs.launchpad.net/keystone
|
||||||
|
|
||||||
[pbr]
|
[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
|
autodoc_tree_index_modules = True
|
||||||
# NOTE(gagehugo): building docs with autodoc_tree_index_modules set to True
|
# NOTE(gagehugo): building docs with autodoc_tree_index_modules set to True
|
||||||
# causes warnings when creating api docs with keystone_tempest_plugin and
|
# causes warnings when creating api docs with keystone_tempest_plugin and
|
||||||
# these issues seem to be related to tempest/oslo_config rather than
|
# these issues seem to be related to tempest/oslo_config rather than
|
||||||
# keystone.
|
# keystone.
|
||||||
autodoc_tree_excludes = keystone_tempest_plugin
|
autodoc_tree_excludes = keystone_tempest_plugin setup.py
|
||||||
|
|
||||||
[entry_points]
|
[entry_points]
|
||||||
console_scripts =
|
console_scripts =
|
||||||
|
|
Loading…
Reference in New Issue