From d7be2902ad504b6fef74eb04c09a14462b028b9d Mon Sep 17 00:00:00 2001
From: Fabio Giannetti <fabio.giannetti@hp.com>
Date: Tue, 4 Feb 2014 12:17:52 -0800
Subject: [PATCH] Style the code examples in docs as python

Add the appropriate styling macro for the code snippets in the
documentation. This change highlights the language syntax making
the documentation more readable.

Closes-Bug: #1276299

Change-Id: Id331be204f688ccbb6e9f2c7ab9287310477312b
---
 doc/source/architecture.rst  |  8 ++++++--
 doc/source/developing.rst    | 24 ++++++++++++++++++------
 doc/source/external-auth.rst |  4 +++-
 3 files changed, 27 insertions(+), 9 deletions(-)

diff --git a/doc/source/architecture.rst b/doc/source/architecture.rst
index 02e6011341..5af8c6c54d 100644
--- a/doc/source/architecture.rst
+++ b/doc/source/architecture.rst
@@ -231,7 +231,9 @@ Rules
 -----
 
 Given a list of matches to check for, simply verify that the credentials
-contain the matches. For example::
+contain the matches. For example:
+
+.. code:: python
 
   credentials = {'user_id': 'foo', 'is_admin': 1, 'roles': ['nova:netadmin']}
 
@@ -255,7 +257,9 @@ Capability RBAC
 (Not yet implemented.)
 
 Another approach to authorization can be action-based, with a mapping of roles
-to which capabilities are allowed for that role. For example::
+to which capabilities are allowed for that role. For example:
+
+.. code:: python
 
   credentials = {'user_id': 'foo', 'is_admin': 1, 'roles': ['nova:netadmin']}
 
diff --git a/doc/source/developing.rst b/doc/source/developing.rst
index 7d39fc884e..18afc109a8 100644
--- a/doc/source/developing.rst
+++ b/doc/source/developing.rst
@@ -346,7 +346,9 @@ which will provide a reference, to a function, that will consult the global cach
         calling ``should_cache_fn``, the returned function reference will default to enabling
         caching for that ``manager``.
 
-Example use of cache and ``should_cache_fn`` (in this example, ``token`` is the manager)::
+Example use of cache and ``should_cache_fn`` (in this example, ``token`` is the manager):
+
+.. code:: python
 
     from keystone.common import cache
     SHOULD_CACHE = cache.should_cache_fn('token')
@@ -372,7 +374,9 @@ If the ``expiration_time`` argument passed to the decorator is set to ``None``,
 time will be set to the global default (``expiration_time`` option in the ``[cache]``
 configuration section.
 
-Example of using a section specific ``cache_time`` (in this example, ``identity`` is the manager)::
+Example of using a section specific ``cache_time`` (in this example, ``identity`` is the manager):
+
+.. code:: python
 
     from keystone.common import cache
     SHOULD_CACHE = cache.should_cache_fn('identity')
@@ -387,7 +391,9 @@ For cache invalidation, the ``on_arguments`` decorator will add an ``invalidate`
 (attribute) to your decorated function.  To invalidate the cache, you pass the same arguments
 to the ``invalidate`` method as you would the normal function.
 
-Example (using the above cacheable_function)::
+Example (using the above cacheable_function):
+
+.. code:: python
 
     def invalidate_cache(arg1, arg2, arg3):
         cacheable_function.invalidate(arg1, arg2, arg3)
@@ -420,7 +426,9 @@ be configured before use. The KVS object will only be retrievable with the
 Once all references have been removed the object is gone (the registry uses a ``weakref`` to
 match the object to the name).
 
-Example Instantiation and Configuration::
+Example Instantiation and Configuration:
+
+.. code:: python
 
     kvs_store = kvs.get_key_value_store('TestKVSRegion')
     kvs_store.configure('openstack.kvs.Memory', ...)
@@ -434,13 +442,17 @@ provided dogpile.cache memcached backends (``BMemcached``, ``pylibmc``, and basi
 By default the standard Memcache backend is used.  Currently the Memcache URLs come from the
 ``servers`` option in the ``[memcache]`` configuration section of the Keystone config.
 
-Example configuring the KVS system to use memcached and a specific dogpile.cache memcached backend::
+Example configuring the KVS system to use memcached and a specific dogpile.cache memcached backend:
+
+.. code:: python
 
     kvs_store = kvs.get_key_value_store('TestKVSRegion')
     kvs_store.configure('openstack.kvs.Memcached', dogpile_cache_backend='MemcachedBackend')
 
 Once a KVS object has been instantiated the method of interacting is the same as most memcache
-implementations::
+implementations:
+
+.. code:: python
 
     kvs_store = kvs.get_key_value_store('TestKVSRegion')
     kvs_store.configure(...)
diff --git a/doc/source/external-auth.rst b/doc/source/external-auth.rst
index 7d18672d60..7012884e86 100644
--- a/doc/source/external-auth.rst
+++ b/doc/source/external-auth.rst
@@ -95,7 +95,9 @@ user must exist in advance in the identity backend so that a proper token can
 be issued.
 
 Your code should set the ``REMOTE_USER`` if the user is properly authenticated,
-following the semantics below::
+following the semantics below:
+
+.. code:: python
 
     from keystone.common import wsgi