bug 1159888 broken links in rst doc

Change-Id: Iad8e63ab57c927032e4bafab79c1f22cb485173f

doc/source/configuringservices.rst

@@ -21,9 +21,10 @@ Configuring Services to work with Keystone
 .. toctree::
    :maxdepth: 1
 
-   middlewarearchitecture
+..  _middlewarearchitecture: middlewarearchitecture.rst
+..  _configuration: configuration.rst
 
-Once Keystone is installed and running (see :doc:`configuration`), services
+Once Keystone is installed and running (see configuration_), services
 need to be configured to work with it. To do this, we primarily install and
 configure middleware for the OpenStack service to handle authentication tasks
 or otherwise interact with Keystone.
@@ -38,7 +39,7 @@ In general:
 
 The middleware will pass those data down to the service as headers. More
 details on the architecture of that setup is described in
-:doc:`middlewarearchitecture`
+middlewarearchitecture_
 
 Setting up credentials
 ======================
@@ -70,7 +71,7 @@ be able to use to authenticate users against keystone. The ``auth_token``
 middleware supports using either the shared secret described above as
 `admin_token` or users for each service.
 
-See :doc:`configuration` for a walk through on how to create tenants, users,
+See configuration_ for a walk through on how to create tenants, users,
 and roles.
 
 Setting up services
@@ -113,7 +114,7 @@ up quickly with::
 
 Once you have it, assign the service users to the Admin role. This is all
 assuming that you've already created the basic roles and settings as described
-in :doc:`configuration`::
+in configuration_:
 
     keystone user-role-add --tenant_id=[uuid of the service tenant] \
                            --user=[uuid of the service account] \
@@ -162,7 +163,7 @@ Keystone Auth-Token Middleware
 
 The Keystone auth_token middleware is a WSGI component that can be inserted in
 the WSGI pipeline to handle authenticating tokens with Keystone. You can
-get more details of the middleware in :doc:`middlewarearchitecture`.
+get more details of the middleware in middlewarearchitecture_.
 
 Configuring Nova to use Keystone
 --------------------------------

doc/source/developing.rst

@@ -33,8 +33,11 @@ To contribute tests, docs, code, etc, refer to our `Gerrit-Jenkins-Github Workfl
 
 Setup
 -----
+.. _setup: setup.rst
+.. _configuration: configuration.rst
+.. _keystonemanage: man/keystone-manage.rst
 
-Get your development environment set up according to :doc:`setup`. The
+Get your development environment set up according to setup_. The
 instructions from here will assume that you have installed keystone into a
 virtualenv. If you chose not to, simply exclude "tools/with_venv.sh" from the
 example commands below.
@@ -48,7 +51,7 @@ To run the keystone Admin and API server instances, use::
     $ tools/with_venv.sh bin/keystone-all
 
 this runs keystone with the configuration the etc/ directory of the project.
-See :doc:`configuration` for details on how Keystone is configured. By default,
+See configuration_ for details on how Keystone is configured. By default,
 keystone is configured with KVS backends, so any data entered into keystone run
 in this fashion will not persist across restarts.
 
@@ -57,7 +60,7 @@ Interacting with Keystone
 -------------------------
 
 You can interact with Keystone through the command line using
-:doc:`man/keystone-manage` which allows you to establish tenants, users, etc.
+keystonemanage_ which allows you to establish tenants, users, etc.
 
 
 You can also interact with Keystone through its REST API. There is a python

doc/source/installing.rst

@@ -18,10 +18,14 @@
 ===================
 Installing Keystone
 ===================
+.. _developing: developing.rst
+.. _setup: setup.rst
+.. _configuration: configuration.rst
+.. _configuring-services: configuringservices.rst
 
 This document describes how to install Keystone in order to use it. If you are
-intending to develop on or with Keystone, please read :doc:`developing` and
-:doc:`setup`
+intending to develop on or with Keystone, please read developing_ and
+setup_.
 
 Installing from Source
 ----------------------
@@ -62,15 +66,15 @@ You will find sample configuration files in ``etc/``
 * policy.json
 * default_catalog.templates
 
-From here, refer to :doc:`configuration` to choose which backend drivers to
+From here, refer to configuration_ to choose which backend drivers to
 enable and use. Once configured, you should be able to run keystone by issuing
 the command::
 
     keystone-all
 
 which (by default) will show logging on the console from which it was started.
 Once started, you can initialize data in keystone for use with the rest of
-openstack, as described in :doc:`configuringservices`.
+openstack, as described in configuring-services_.
 
 An excellent reference implementation of setting up keystone is DEVSTACK_,
 most commonly used for development and testing setup of not only Keystone,
@@ -98,7 +102,7 @@ options for setting up and running Keystone. As of this writing, the defaults
 for Keystone backends are all SQL based, stored locally in a sqlite.
 
 Once installed, you still need to initialize data in Keystone, which you can
-find described in :doc:`configuringservices`.
+find described in configuring-services_.
 
 Installing from packages: Fedora
 --------------------------------

doc/source/middlewarearchitecture.rst

@@ -20,6 +20,7 @@ Middleware Architecture
 
 Abstract
 ========
+..  _architecture: architecture.rst
 
 The Keystone middleware architecture supports a common authentication protocol
 in use between the OpenStack projects. By using keystone as a common
@@ -32,7 +33,7 @@ authentication middleware which acts as the internal API mechanism for
 OpenStack projects based on the WSGI standard.
 
 For the architecture of keystone and its services, please see
-:doc:`architecture`. This documentation primarily describes the implementation
+architecture_. This documentation primarily describes the implementation
 in ``keystoneclient/middleware/auth_token.py``
 (:py:class:`keystoneclient.middleware.auth_token.AuthProtocol`)
 
@@ -77,7 +78,7 @@ Figure 1. Authentication Component
 
 The middleware may also be configured to operated in a 'delegated mode'.
 In this mode, the decision reject an unauthenticated client is delegated to
-the OpenStack service, as illustrated in :ref:`authComponentDelegated`.
+the OpenStack service, as illustrated below.
 
 Here, requests are forwarded to the OpenStack service with an identity status
 message that indicates whether the client's identity has been confirmed or is
@@ -219,7 +220,7 @@ unsuccessful.
 Extended the request with additional User Information
 -----------------------------------------------------
 
-:py:class:`keystoneclient.middleware.auth_token.AuthProtocol` extends the request
+The keystone client auth_token middleware extends the request
 with additional information if the user has been authenticated.
 
 

doc/source/setup.rst

@@ -26,6 +26,7 @@ Documentation`_.
 
 .. _`GitHub Repository`: http://github.com/openstack/keystone
 .. _`User Documentation`: http://docs.openstack.org/
+.. _developing: developing.rst
 
 Prerequisites
 =============
@@ -149,7 +150,7 @@ without issue::
     >>>
 
 If you can import keystone successfully, you should be ready to move on to
-:doc:`developing`
+developing_.
 
 Troubleshooting
 ===============