134 lines
5.0 KiB
ReStructuredText
134 lines
5.0 KiB
ReStructuredText
.. :orphan:
|
|
|
|
Caching layer
|
|
~~~~~~~~~~~~~
|
|
|
|
OpenStack Identity supports a caching layer that is above the
|
|
configurable subsystems (for example, token, assignment). OpenStack
|
|
Identity uses the
|
|
`dogpile.cache <http://dogpilecache.readthedocs.org/en/latest/>`__
|
|
library which allows flexible cache back ends. The majority of the
|
|
caching configuration options are set in the ``[cache]`` section of the
|
|
``keystone.conf`` file. However, each section that has the capability to
|
|
be cached usually has a caching boolean value that toggles caching.
|
|
|
|
So to enable only the token back end caching, set the values as follows:
|
|
|
|
.. code-block:: ini
|
|
|
|
[cache]
|
|
enabled=true
|
|
|
|
[assignment]
|
|
caching=false
|
|
|
|
[token]
|
|
caching=true
|
|
|
|
.. note::
|
|
|
|
Since the Juno release, the default setting is enabled for subsystem
|
|
caching, but the global toggle is disabled. As a result, no caching
|
|
in available unless the global toggle for ``[cache]`` is enabled by
|
|
setting the value to ``true``.
|
|
|
|
Caching for tokens and tokens validation
|
|
----------------------------------------
|
|
|
|
The token system has a separate ``cache_time`` configuration option,
|
|
that can be set to a value above or below the global ``expiration_time``
|
|
default, allowing for different caching behavior from the other systems
|
|
in OpenStack Identity. This option is set in the ``[token]`` section of
|
|
the configuration file.
|
|
|
|
The token revocation list cache time is handled by the configuration
|
|
option ``revocation_cache_time`` in the ``[token]`` section. The
|
|
revocation list is refreshed whenever a token is revoked. It typically
|
|
sees significantly more requests than specific token retrievals or token
|
|
validation calls.
|
|
|
|
Here is a list of actions that are affected by the cached time: getting
|
|
a new token, revoking tokens, validating tokens, checking v2 tokens, and
|
|
checking v3 tokens.
|
|
|
|
The delete token API calls invalidate the cache for the tokens being
|
|
acted upon, as well as invalidating the cache for the revoked token list
|
|
and the validate/check token calls.
|
|
|
|
Token caching is configurable independently of the ``revocation_list``
|
|
caching. Lifted expiration checks from the token drivers to the token
|
|
manager. This ensures that cached tokens will still raise a
|
|
``TokenNotFound`` flag when expired.
|
|
|
|
For cache consistency, all token IDs are transformed into the short
|
|
token hash at the provider and token driver level. Some methods have
|
|
access to the full ID (PKI Tokens), and some methods do not. Cache
|
|
invalidation is inconsistent without token ID normalization.
|
|
|
|
Caching around assignment CRUD
|
|
------------------------------
|
|
|
|
The assignment system has a separate ``cache_time`` configuration
|
|
option, that can be set to a value above or below the global
|
|
``expiration_time`` default, allowing for different caching behavior
|
|
from the other systems in Identity service. This option is set in the
|
|
``[assignment]`` section of the configuration file.
|
|
|
|
Currently ``assignment`` has caching for ``project``, ``domain``, and
|
|
``role`` specific requests (primarily around the CRUD actions). Caching
|
|
is currently not implemented on grants. The ``list`` methods are not
|
|
subject to caching.
|
|
|
|
Here is a list of actions that are affected by the assignment: assign
|
|
domain API, assign project API, and assign role API.
|
|
|
|
The create, update, and delete actions for domains, projects and roles
|
|
will perform proper invalidations of the cached methods listed above.
|
|
|
|
.. note::
|
|
|
|
If a read-only ``assignment`` back end is in use, the cache will not
|
|
immediately reflect changes on the back end. Any given change may
|
|
take up to the ``cache_time`` (if set in the ``[assignment]``
|
|
section of the configuration file) or the global ``expiration_time``
|
|
(set in the ``[cache]`` section of the configuration file) before it
|
|
is reflected. If this type of delay (when using a read-only
|
|
``assignment`` back end) is an issue, it is recommended that caching
|
|
be disabled on ``assignment``. To disable caching specifically on
|
|
``assignment``, in the ``[assignment]`` section of the configuration
|
|
set ``caching`` to ``False``.
|
|
|
|
For more information about the different back ends (and configuration
|
|
options), see:
|
|
|
|
- `dogpile.cache.backends.memory <http://dogpilecache.readthedocs.org/en/latest/api.html#memory-backend>`__
|
|
|
|
- `dogpile.cache.backends.memcached <http://dogpilecache.readthedocs.org/en/latest/api.html#memcached-backends>`__
|
|
|
|
.. note::
|
|
|
|
The memory back end is not suitable for use in a production
|
|
environment.
|
|
|
|
- `dogpile.cache.backends.redis <http://dogpilecache.readthedocs.org/en/latest/api.html#redis-backends>`__
|
|
|
|
- `dogpile.cache.backends.file <http://dogpilecache.readthedocs.org/en/latest/api.html#file-backends>`__
|
|
|
|
- ``keystone.common.cache.backends.mongo``
|
|
|
|
Configure the Memcached back end example
|
|
----------------------------------------
|
|
|
|
The following example shows how to configure the memcached back end:
|
|
|
|
.. code-block:: ini
|
|
|
|
[cache]
|
|
|
|
enabled = true
|
|
backend = dogpile.cache.memcached
|
|
backend_argument = url:127.0.0.1:11211
|
|
|
|
You need to specify the URL to reach the ``memcached`` instance with the
|
|
``backend_argument`` parameter.
|