openstack
/
keystone
Code Issues Proposed changes

Merged the caching subsections in admin docs 

Currently there are two subsections named caching layer in
the admin docs. This commit merges the information in the
two and removes the duplicate docs.

Change-Id: I0f8a89c0eccc2ad6078b4d21dae274df3fc9da18
This commit is contained in:
Samriddhi Jain 2017-07-12 20:46:18 +05:30
parent 9b3d99ea24
commit 4bbc505e71
3 changed files with 28 additions and 38 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

35
doc/source/admin/caching.rst
View File

@ -1,35 +0,0 @@
=============
Caching layer
=============
Identity supports a caching layer that is above the configurable subsystems,
such as token or assignment. The majority of the caching configuration options
are set in the ``[cache]`` section. However, each section that has the
capability to be cached usually has a ``caching`` option that will toggle
caching for that specific section. By default, caching is globally disabled.
Current functional back ends are:
``dogpile.cache.memcached``
Memcached back end using the standard ``python-memcached`` library.
``dogpile.cache.pylibmc``
Memcached back end using the ``pylibmc`` library.
``dogpile.cache.bmemcached``
Memcached using the ``python-binary-memcached`` library.
``dogpile.cache.redis``
Redis back end.
``dogpile.cache.dbm``
Local DBM file back end.
``dogpile.cache.memory``
In-memory cache, not suitable for use outside of testing as it does not
cleanup its internal cache on cache expiration and does not share cache
between processes. This means that caching and cache invalidation will not
be consistent or reliable.
``dogpile.cache.mongo``
MongoDB as caching back end.

30
doc/source/admin/identity-caching-layer.rst
View File

@ -11,8 +11,8 @@ flexible cache back ends. The majority of the caching configuration options are
set in the ``[cache]`` section of the ``/etc/keystone/keystone.conf`` file. The
``enabled`` option of the ``[cache]`` section must be set to ``True`` in order
for any subsystem to cache responses. Each section that has the capability to
be cached will have a caching boolean value that toggles caching behavior of
that particular subsystem.
be cached will have a ``caching`` boolean value that toggles caching behavior
of that particular subsystem.
So to enable only the token back end caching, set the values as follows:
@ -48,6 +48,32 @@ So to enable only the token back end caching, set the values as follows:
toggle for caching defaults to ``False``. A subsystem is only able to cache
responses if the global toggle is enabled.
Current functional back ends are:
``dogpile.cache.memcached``
Memcached back end using the standard ``python-memcached`` library.
``dogpile.cache.pylibmc``
Memcached back end using the ``pylibmc`` library.
``dogpile.cache.bmemcached``
Memcached using the ``python-binary-memcached`` library.
``dogpile.cache.redis``
Redis back end.
``dogpile.cache.dbm``
Local DBM file back end.
``dogpile.cache.memory``
In-memory cache, not suitable for use outside of testing as it does not
cleanup its internal cache on cache expiration and does not share cache
between processes. This means that caching and cache invalidation will not
be consistent or reliable.
``dogpile.cache.mongo``
MongoDB as caching back end.
Caching for tokens and tokens validation
----------------------------------------

1
doc/source/admin/identity-management.rst
View File

@ -32,4 +32,3 @@ command-line client.
identity-troubleshoot.rst
token-provider.rst
federated-identity.rst
caching.rst