Merge "Remove pbr warnerrors in favor of sphinx check"

This commit is contained in:
Jenkins 2017-03-09 01:21:36 +00:00 committed by Gerrit Code Review
commit 7048b6759b
6 changed files with 73 additions and 91 deletions

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',

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": [

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"

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>

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>

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 =