[ops-guide] Cleanup arch examples chapter

Change-Id: I5d229acce9a316fc22c9c82f7338dfae7f0a9004
Implements: blueprint ops-guide-rst

doc/ops-guide/source/arch_example_neutron.rst

@@ -110,11 +110,13 @@ Node types
 This section gives you a breakdown of the different nodes that make up
 the OpenStack environment. A node is a physical machine that is
 provisioned with an operating system, and running a defined software
-stack on top of it. The table below provides node descriptions and
+stack on top of it. :ref:`table_node_types` provides node descriptions and
 specifications.
 
-.. list-table:: Node types
+.. _table_node_types:
-   :widths: 33 33 33
+
+.. list-table:: Table. Node types
+   :widths: 20 50 30
    :header-rows: 1
 
    * - Type
@@ -297,40 +299,45 @@ Initial deployment
 
 Initially, the connection setup should revolve around keeping the
 connectivity simple and straightforward in order to minimize deployment
-complexity and time to deploy. The deployment shown below aims to have 1 × 10G
+complexity and time to deploy.
-connectivity available to all compute nodes, while still leveraging bonding on
+The deployment shown in :ref:`figure_basic_node_deployment` aims to
-appropriate nodes for maximum performance.
+have 1 × 10G connectivity available to all compute nodes, while still
+leveraging bonding on appropriate nodes for maximum performance.
+
+.. _figure_basic_node_deployment:
 
 .. figure:: figures/osog_0101.png
    :alt: Basic node deployment
    :width: 100%
 
-   Basic node deployment
+   Figure. Basic node deployment
 
 
 Connectivity for maximum performance
 ------------------------------------
 
 If the networking performance of the basic layout is not enough, you can
-move to the design below, which provides 2 × 10G network
+move to :ref:`figure_performance_node_deployment`, which provides 2 × 10G
-links to all instances in the environment as well as providing more
+network links to all instances in the environment as well as providing more
 network bandwidth to the storage layer.
 
+.. _figure_performance_node_deployment:
+
 .. figure:: figures/osog_0102.png
    :alt: Performance node deployment
    :width: 100%
 
-   Performance node deployment
+   Figure. Performance node deployment
 
 
 Node diagrams
 ~~~~~~~~~~~~~
 
-The following diagrams include logical
+The following diagrams, :ref:`controller_node` through :ref:`storage_node`,
-information about the different types of nodes, indicating what services
+include logical information about the different types of nodes, indicating
-will be running on top of them and how they interact with each other.
+what services will be running on top of them and how they interact with
-The diagrams also illustrate how the availability and scalability of
+each other. The diagrams also illustrate how the availability and
-services are achieved.
+scalability of services are achieved.
 
 .. _controller_node:
 
@@ -338,7 +345,7 @@ services are achieved.
    :alt: Controller node
    :width: 100%
 
-   Controller node
+   Figure. Controller node
 
 .. _compute_node:
 
@@ -346,7 +353,7 @@ services are achieved.
    :alt: Compute node
    :width: 100%
 
-   Compute node
+   Figure. Compute node
 
 .. _network_node:
 
@@ -354,7 +361,7 @@ services are achieved.
    :alt: Network node
    :width: 100%
 
-   Network node
+   Figure. Network node
 
 .. _storage_node:
 
@@ -362,17 +369,20 @@ services are achieved.
    :alt: Storage node
    :width: 100%
 
-   Storage node
+   Figure. Storage node
 
 
 Example Component Configuration
 -------------------------------
 
-The following tables include example configuration
+:ref:`third_party_component_configuration` and
+:ref:`openstack_component_configuration` include example configuration
 and considerations for both third-party and OpenStack components:
 
-.. list-table:: Table: Third-party component configuration
+.. _third_party_component_configuration:
-   :widths: 25 25 25 25
+
+.. list-table:: Table. Third-party component configuration
+   :widths: 10 30 30 30
    :header-rows: 1
 
    * - Component
@@ -454,8 +464,10 @@ and considerations for both third-party and OpenStack components:
 
 |
 
-.. list-table:: Table: OpenStack component configuration
+.. _openstack_component_configuration:
-   :widths: 20 20 20 20 20
+
+.. list-table:: Table. OpenStack component configuration
+   :widths: 10 10 20 30 30
    :header-rows: 1
 
    * - Component
@@ -523,7 +535,7 @@ and considerations for both third-party and OpenStack components:
        achieved linearly by adding in more compute nodes.
    * - Block Storage (cinder)
      - Controller
-     - Configured to use Qpid, ``qpid_heartbeat = ``\ ``10``,configured to
+     - Configured to use Qpid, ``qpid_heartbeat = ``10``,configured to
        use a Gluster volume from the storage layer as the back end for
        Block Storage, using the Gluster native client.
      - Block Storage API, scheduler, and volume services are run on all

doc/ops-guide/source/arch_example_nova_network.rst

@@ -75,27 +75,27 @@ those deviations next.
     -  :term:`Dashboard`: You probably want to offer a dashboard, but your
        users may be more interested in API access only.
 
-    -  Block storage: You don't have to offer users block storage if
+    -  :term:`Block storage <Block Storage service>`:
-       their use case only needs ephemeral storage on compute nodes, for
+       You don't have to offer users block storage if their use case only
-       example.
+       needs ephemeral storage on compute nodes, for example.
 
-    -  Floating IP address: Floating IP addresses are public IP
+    -  :term:`Floating IP address <floating IP address>`:
-       addresses that you allocate from a predefined pool to assign to
+       Floating IP addresses are public IP addresses that you allocate
-       virtual machines at launch. Floating IP address ensure that the
+       from a predefined pool to assign to virtual machines at launch.
-       public IP address is available whenever an instance is booted.
+       Floating IP address ensure that the public IP address is available
-       Not every organization can offer thousands of public floating IP
+       whenever an instance is booted. Not every organization can offer
-       addresses for thousands of instances, so this feature is
+       thousands of public floating IP addresses for thousands of
-       considered optional.
+       instances, so this feature is considered optional.
 
-    -  Live migration: If you need to move running virtual machine
+    -  :term:`Live migration <live migration>`: If you need to move
-       instances from one host to another with little or no service
+       running virtual machine instances from one host to another with
-       interruption, you would enable live migration, but it is
+       little or no service interruption, you would enable live migration,
-       considered optional.
+       but it is considered optional.
 
-    -  Object storage: You may choose to store machine images on a file
+    -  :term:`Object storage <Object Storage service>`: You may choose to
-       system rather than in object storage if you do not have the extra
+       store machine images on a file system rather than in object storage
-       hardware for the required replication and redundancy that
+       if you do not have the extra hardware for the required replication
-       OpenStack Object Storage offers.
+       and redundancy that OpenStack Object Storage offers.
 
 Rationale
 ~~~~~~~~~
@@ -157,7 +157,7 @@ We chose the *SQL back end for Identity* over others, such as LDAP. This
 back end is simple to install and is robust. The authors acknowledge
 that many installations want to bind with existing directory services
 and caution careful understanding of the `array of options available
-<http://docs.openstack.org/havana/config-reference/content/ch_configuring-openstack-identity.html#configuring-keystone-for-ldap-backend>`_.
+<http://docs.openstack.org/mitaka/config-reference/identity/options.html#keystone-ldap>`_.
 
 Block Storage (cinder) is installed natively on external storage nodes
 and uses the *LVM/iSCSI plug-in*. Most Block Storage plug-ins are tied
@@ -191,12 +191,12 @@ and the instances cannot access the Internet. The single node that runs
 the ``nova-network`` service can become a bottleneck if excessive
 network traffic comes in and goes out of the cloud.
 
-.. note::
+.. tip::
 
-    `Multi-host <http://docs.openstack.org/havana/install-guide/install/apt/content/nova-network.html>`_
+   `Multi-host <http://docs.openstack.org/havana/install-guide/install/apt/content/nova-network.html>`_
-    is a high-availability option for the network configuration, where
+   is a high-availability option for the network configuration, where
-    the ``nova-network`` service is run on every compute node instead of
+   the ``nova-network`` service is run on every compute node instead of
-    running on only a single node.
+   running on only a single node.
 
 Detailed Description
 --------------------
@@ -253,7 +253,8 @@ optional extensions follows:
 -  Add additional cloud controllers (see :doc:`ops_maintenance`).
 
 -  Add an OpenStack Storage service (see the Object Storage chapter in
-   the *OpenStack Installation Guide* for your distribution).
+   the `OpenStack Installation Guide
+   <http://docs.openstack.org/#install-guides>`_ for your distribution).
 
 -  Add additional OpenStack Block Storage hosts (see
    :doc:`ops_maintenance`).

doc/ops-guide/source/arch_examples.rst

@@ -17,7 +17,7 @@ documenting, as well as to provide the scope for this guide. Both of the
 offered architecture examples are currently running in production and
 serving users.
 
-.. note::
+.. tip::
 
    As always, refer to the :doc:`common/glossary` if you are unclear
    about any of the terminology mentioned in architecture examples.