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
|
||||
# ones.
|
||||
extensions = ['sphinx.ext.autodoc',
|
||||
'sphinx.ext.todo',
|
||||
'sphinx.ext.coverage',
|
||||
'sphinx.ext.viewcode',
|
||||
'oslo_config.sphinxconfiggen',
|
||||
|
@ -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": [
|
||||
|
@ -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"
|
||||
|
@ -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>
|
||||
|
||||
|
@ -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>
|
||||
|
||||
|
@ -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 =
|
||||
|
Loading…
Reference in New Issue
Block a user