summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
-rw-r--r--api-ref/source/v3/unified_limits.inc4
-rw-r--r--doc/source/admin/auth-totp.rst4
-rw-r--r--doc/source/admin/service-api-protection.rst2
-rw-r--r--doc/source/install/index-obs.rst8
-rw-r--r--doc/source/install/index-rdo.rst8
-rw-r--r--doc/source/install/index-ubuntu.rst8
-rw-r--r--doc/source/user/application_credentials.rst43
-rw-r--r--keystone/tests/unit/base_classes.py9
8 files changed, 51 insertions, 35 deletions
diff --git a/api-ref/source/v3/unified_limits.inc b/api-ref/source/v3/unified_limits.inc
index ce32a0f1c..bdb1d1959 100644
--- a/api-ref/source/v3/unified_limits.inc
+++ b/api-ref/source/v3/unified_limits.inc
@@ -614,8 +614,8 @@ Example
:language: javascript
-Delete Registered Limit
-=======================
+Delete Limit
+============
.. rest_method:: DELETE /v3/limits/{limit_id}
diff --git a/doc/source/admin/auth-totp.rst b/doc/source/admin/auth-totp.rst
index 3c331be96..c77ca64a0 100644
--- a/doc/source/admin/auth-totp.rst
+++ b/doc/source/admin/auth-totp.rst
@@ -40,8 +40,8 @@ secret:
.. code-block:: python
import base64
- message = '1234567890123456'
- print base64.b32encode(message).rstrip('=')
+ message = b'1234567890123456'
+ print(base64.b32encode(message).rstrip(b'='))
Example output::
diff --git a/doc/source/admin/service-api-protection.rst b/doc/source/admin/service-api-protection.rst
index 47886aeb0..249944354 100644
--- a/doc/source/admin/service-api-protection.rst
+++ b/doc/source/admin/service-api-protection.rst
@@ -31,7 +31,7 @@ custom policies.
Roles Definitions
-----------------
-The default roles provided by keystone, via ``keystone-manage boostrap``, are
+The default roles provided by keystone, via ``keystone-manage bootstrap``, are
related through role implications. The ``admin`` role implies the ``member``
role, and the ``member`` role implies the ``reader`` role. These implications
mean users with the ``admin`` role automatically have the ``member`` and
diff --git a/doc/source/install/index-obs.rst b/doc/source/install/index-obs.rst
index c67974d74..46129285a 100644
--- a/doc/source/install/index-obs.rst
+++ b/doc/source/install/index-obs.rst
@@ -12,14 +12,6 @@ both SP1 and SP2 - through the Open Build Service Cloud repository.
Explanations of configuration options and sample configuration files
are included.
-.. note::
- The Training Labs scripts provide an automated way of deploying the
- cluster described in this Installation Guide into VirtualBox or KVM
- VMs. You will need a desktop computer or a laptop with at least 8
- GB memory and 20 GB free storage running Linux, MacOS, or Windows.
- Please see the
- `OpenStack Training Labs <https://docs.openstack.org/training_labs/>`_.
-
.. warning::
This guide is a work-in-progress and is subject to updates frequently.
diff --git a/doc/source/install/index-rdo.rst b/doc/source/install/index-rdo.rst
index 6e0e3984f..dc48e890f 100644
--- a/doc/source/install/index-rdo.rst
+++ b/doc/source/install/index-rdo.rst
@@ -12,14 +12,6 @@ the RDO repository.
Explanations of configuration options and sample configuration files
are included.
-.. note::
- The Training Labs scripts provide an automated way of deploying the
- cluster described in this Installation Guide into VirtualBox or KVM
- VMs. You will need a desktop computer or a laptop with at least 8
- GB memory and 20 GB free storage running Linux, MacOS, or Windows.
- Please see the
- `OpenStack Training Labs <https://docs.openstack.org/training_labs/>`_.
-
.. warning::
This guide is a work-in-progress and is subject to updates frequently.
diff --git a/doc/source/install/index-ubuntu.rst b/doc/source/install/index-ubuntu.rst
index b3e5cb064..d1c7fe138 100644
--- a/doc/source/install/index-ubuntu.rst
+++ b/doc/source/install/index-ubuntu.rst
@@ -12,14 +12,6 @@ Ubuntu 16.04 (LTS).
Explanations of configuration options and sample configuration files
are included.
-.. note::
- The Training Labs scripts provide an automated way of deploying the
- cluster described in this Installation Guide into VirtualBox or KVM
- VMs. You will need a desktop computer or a laptop with at least 8
- GB memory and 20 GB free storage running Linux, MacOS, or Windows.
- Please see the
- `OpenStack Training Labs <https://docs.openstack.org/training_labs/>`_.
-
.. warning::
This guide is a work-in-progress and is subject to updates frequently.
diff --git a/doc/source/user/application_credentials.rst b/doc/source/user/application_credentials.rst
index eff86f7b3..5455a04e7 100644
--- a/doc/source/user/application_credentials.rst
+++ b/doc/source/user/application_credentials.rst
@@ -174,8 +174,47 @@ Access Rules
============
In addition to delegating a subset of roles to an application credential, you
-may also delegate more fine-grained access control by using access rules. For
-example, to create an application credential that is constricted to creating
+may also delegate more fine-grained access control by using access rules.
+
+.. note::
+
+ Application credentials with access rules require additional configuration
+ of each service that will use it. See below for details.
+
+If application credentials with access rules are required, an OpenStack
+service using keystonemiddleware to authenticate with keystone, needs to
+define ``service_type`` in its configuration file. Following is an example for the
+cinder V3 service:
+
+.. code-block:: ini
+
+ [keystone_authtoken]
+ service_type = volumev3
+
+For other OpenStack sevices, their types can be obtained using the OpenStack
+client. For example:
+
+.. code-block:: console
+
+ $ openstack service list -c Name -c Type
+ +-----------+-----------+
+ | Name | Type |
+ +-----------+-----------+
+ | glance | image |
+ | cinderv3 | volumev3 |
+ | cinderv2 | volumev2 |
+ | keystone | identity |
+ | nova | compute |
+ | neutron | network |
+ | placement | placement |
+ +-----------+-----------+
+
+.. note::
+
+ Updates to the configuration files of a service require restart of the appropriate
+ services for the changes to take effect.
+
+In order to create an example application credential that is constricted to creating
servers in nova, the user can add the following access rules:
.. code-block:: console
diff --git a/keystone/tests/unit/base_classes.py b/keystone/tests/unit/base_classes.py
index 95bf7fa02..9bf3b50eb 100644
--- a/keystone/tests/unit/base_classes.py
+++ b/keystone/tests/unit/base_classes.py
@@ -31,7 +31,7 @@ class TestCaseWithBootstrap(core.BaseTestCase):
Re-implementation of TestCase that doesn't load a bunch of fixtures by
hand and instead uses the bootstrap process. This makes it so that our base
tests have the same things available to us as operators after they run
- boostrap. It also makes our tests DRY and pushes setup required for
+ bootstrap. It also makes our tests DRY and pushes setup required for
specific tests into the actual test class, instead of pushing it into a
generic structure that gets loaded for every test.
@@ -46,7 +46,7 @@ class TestCaseWithBootstrap(core.BaseTestCase):
ksfixtures.KeyRepository(
self.config_fixture,
'fernet_tokens',
- CONF.fernet_tokens.max_active_keys
+ CONF.fernet_tokens.max_active_keys,
)
)
@@ -54,7 +54,7 @@ class TestCaseWithBootstrap(core.BaseTestCase):
ksfixtures.KeyRepository(
self.config_fixture,
'fernet_receipts',
- CONF.fernet_receipts.max_active_keys
+ CONF.fernet_receipts.max_active_keys,
)
)
@@ -72,7 +72,8 @@ class TestCaseWithBootstrap(core.BaseTestCase):
try:
PROVIDERS.resource_api.create_domain(
default_fixtures.ROOT_DOMAIN['id'],
- default_fixtures.ROOT_DOMAIN)
+ default_fixtures.ROOT_DOMAIN,
+ )
except exception.Conflict:
pass