Merge "[arch-design] Coordinate file names for consistency"

doc/arch-design-rst/source/compute-focus-technical-considerations.rst

@@ -151,11 +151,11 @@ largest flavor is half that size again. The following figure provides a
 visual representation of this concept for a general purpose computing
 design:
 
-.. figure:: /figures/Compute_Tech_Bin_Packing_General1.png
+.. figure:: figures/Compute_Tech_Bin_Packing_General1.png
 
 The following figure displays a CPU-optimized, packed server:
 
-.. figure:: /figures/Compute_Tech_Bin_Packing_CPU_optimized1.png
+.. figure:: figures/Compute_Tech_Bin_Packing_CPU_optimized1.png
 
 These default flavors are well suited to typical configurations of
 commodity server hardware. To maximize utilization, however, it may be

doc/arch-design-rst/source/hybrid-architecture.rst

@@ -10,7 +10,7 @@ the need to create workarounds and processes to fill identified gaps.
 For your chosen cloud management platform, note the relative
 levels of support for both monitoring and orchestration.
 
-.. figure:: ../figures/Multi-Cloud_Priv-AWS4.png
+.. figure:: figures/Multi-Cloud_Priv-AWS4.png
    :width: 100%
 
 Image portability

doc/arch-design-rst/source/hybrid-prescriptive-examples.rst

@@ -29,7 +29,7 @@ This is a custom in-house application written for this specific purpose.
 
 This solution is depicted in the figure below:
 
-.. figure:: ../figures/Multi-Cloud_Priv-Pub3.png
+.. figure:: figures/Multi-Cloud_Priv-Pub3.png
    :width: 100%
 
 This example shows two clouds with a Cloud Management
@@ -60,7 +60,7 @@ to take advantage of additional capacity and to scale applications.
 
 The following diagram demonstrates an OpenStack-to-AWS hybrid cloud:
 
-.. figure:: ../figures/Multi-Cloud_Priv-AWS4.png
+.. figure:: figures/Multi-Cloud_Priv-AWS4.png
    :width: 100%
 
 Company B states that its developers are already using AWS
@@ -101,7 +101,7 @@ To achieve these objectives, Company C replicates data to
 a second cloud in a geographically distant location.
 The following diagram describes this system:
 
-.. figure:: ../figures/Multi-Cloud_failover2.png
+.. figure:: figures/Multi-Cloud_failover2.png
    :width: 100%
 
 This example includes two private OpenStack clouds connected with a CMP.

doc/arch-design-rst/source/hybrid.rst

@@ -5,11 +5,11 @@ Hybrid
 .. toctree::
    :maxdepth: 2
 
-   hybrid/user-requirements-hybrid.rst
-   hybrid/technical-considerations-hybrid.rst
-   hybrid/architecture-hybrid.rst
-   hybrid/operational-considerations-hybrid.rst
-   hybrid/prescriptive-examples-hybrid.rst
+   hybrid-user-requirements.rst
+   hybrid-technical-considerations.rst
+   hybrid-architecture.rst
+   hybrid-operational-considerations.rst
+   hybrid-prescriptive-examples.rst
 
 A :term:`hybrid cloud` design is one that uses more than one cloud.
 For example, designs that use both an OpenStack-based private

doc/arch-design-rst/source/massively-scalable-tech-considerations.rst

@@ -104,4 +104,4 @@ A number of host aggregates enable targeting of virtual machine instances
 using flavors, that require special capabilities shared by the target hosts
 such as SSDs, 10 GbE networks, or GPU cards.
 
-.. figure:: /figures/Massively_Scalable_Cells_regions_azs.png
+.. figure:: figures/Massively_Scalable_Cells_regions_azs.png

doc/arch-design-rst/source/massively-scalable.rst

@@ -5,9 +5,9 @@ Massively scalable
 .. toctree::
    :maxdepth: 2
 
-   user-requirements-massively-scalable.rst
-   tech-considerations-massively-scalable.rst
-   operational-considerations-massively-scalable.rst
+   massively-scalable-user-requirements.rst
+   massively-scalable-tech-considerations.rst
+   massively-scalable-operational-considerations.rst
 
 A massively scalable architecture is a cloud implementation
 that is either a very large deployment, such as a commercial

doc/arch-design-rst/source/network-focus-prescriptive-examples.rst

@@ -27,7 +27,7 @@ vSwitch agent in GRE tunnel mode. This ensures all devices can reach all
 other devices and that you can create tenant networks for private
 addressing links to the load balancer.
 
-.. figure:: /figures/Network_Web_Services1.png
+.. figure:: figures/Network_Web_Services1.png
 
 A web service architecture has many options and optional components. Due
 to this, it can fit into a large number of other OpenStack designs. A
@@ -152,7 +152,7 @@ east-west traffic
  specific direction. However this traffic might interfere with
  north-south traffic.
 
-.. figure:: /figures/Network_Cloud_Storage2.png
+.. figure:: figures/Network_Cloud_Storage2.png
 
 This application prioritizes the north-south traffic over east-west
 traffic: the north-south traffic involves customer-facing data.

doc/arch-design-rst/source/specialized-desktop-as-a-service.rst

@@ -44,5 +44,5 @@ would not suffice for a large scale, enterprise solution.
 Diagram
 ~~~~~~~
 
-.. figure:: ../figures/Specialized_VDI1.png
+.. figure:: figures/Specialized_VDI1.png
    :width: 100%

doc/arch-design-rst/source/specialized-hardware.rst

@@ -39,5 +39,5 @@ implementing and using it, is available at
 `https://wiki.openstack.org/wiki/Pci_passthrough <https://wiki.openstack.org/
 wiki/Pci_passthrough#How_to_check_PCI_status_with_PCI_api_patches>`_.
 
-.. figure:: ../figures/Specialized_Hardware2.png
+.. figure:: figures/Specialized_Hardware2.png
    :width: 100%

doc/arch-design-rst/source/specialized-multi-hypervisor.rst

@@ -16,7 +16,7 @@ on ESXi. The remaining 250 or so have more flexible requirements.
 The financial company decides to manage the
 overall system with a common OpenStack platform.
 
-.. figure:: ../figures/Compute_NSX.png
+.. figure:: figures/Compute_NSX.png
    :width: 100%
 
 Architecture planning teams decided to run a host aggregate

doc/arch-design-rst/source/specialized-openstack-on-openstack.rst

@@ -66,5 +66,5 @@ complex solution for such a use case.
 Diagram
 ~~~~~~~
 
-.. figure:: ../figures/Specialized_OOO.png
+.. figure:: figures/Specialized_OOO.png
    :width: 100%

doc/arch-design-rst/source/specialized-software-defined-networking.rst

@@ -38,10 +38,10 @@ Diagram
 
 OpenStack hosted SDN controller:
 
-.. figure:: ../figures/Specialized_SDN_hosted.png
+.. figure:: figures/Specialized_SDN_hosted.png
    :width: 100%
 
 OpenStack participating in an SDN controller network:
 
-.. figure:: ../figures/Specialized_SDN_external.png
+.. figure:: figures/Specialized_SDN_external.png
    :width: 100%

doc/arch-design-rst/source/specialized.rst

@@ -5,12 +5,12 @@ Specialized cases
 .. toctree::
    :maxdepth: 2
 
-   specialized/multi-hypervisor-specialized.rst
-   specialized/networking-specialized.rst
-   specialized/software-defined-networking-specialized.rst
-   specialized/desktop-as-a-service-specialized.rst
-   specialized/openstack-on-openstack-specialized.rst
-   specialized/hardware-specialized.rst
+   specialized-multi-hypervisor.rst
+   specialized-networking.rst
+   specialized-software-defined-networking.rst
+   specialized-desktop-as-a-service.rst
+   specialized-openstack-on-openstack.rst
+   specialized-hardware.rst
 
 Although most OpenStack architecture designs fall into one
 of the seven major scenarios outlined in other sections
@@ -20,22 +20,20 @@ there are a few use cases that do not fit into these categories.
 This section discusses these specialized cases and provide some
 additional details and design considerations for each use case:
 
-* :doc:`Specialized networking <specialized/networking-specialized>`:
+* :doc:`Specialized networking <specialized-networking>`:
   describes running networking-oriented software that may involve reading
   packets directly from the wire or participating in routing protocols.
 * :doc:`Software-defined networking (SDN)
-  <specialized/software-defined-networking-specialized>`:
+  <specialized-software-defined-networking>`:
   describes both running an SDN controller from within OpenStack
   as well as participating in a software-defined network.
-* :doc:`Desktop-as-a-Service
-  <specialized/desktop-as-a-service-specialized>`:
+* :doc:`Desktop-as-a-Service <specialized-desktop-as-a-service>`:
   describes running a virtualized desktop environment in a cloud
   (:term:`Desktop-as-a-Service`).
   This applies to private and public clouds.
-* :doc:`OpenStack on OpenStack
-  <specialized/openstack-on-openstack-specialized>`:
+* :doc:`OpenStack on OpenStack <specialized-openstack-on-openstack>`:
   describes building a multi-tiered cloud by running OpenStack
   on top of an OpenStack installation.
-* :doc:`Specialized hardware <specialized/hardware-specialized>`:
+* :doc:`Specialized hardware <specialized-hardware>`:
   describes the use of specialized hardware devices from within
   the OpenStack environment.

doc/arch-design-rst/source/storage-focus-prescriptive-examples.rst

@@ -16,7 +16,7 @@ requirement.
 Swift is a highly scalable object store that is part of the OpenStack
 project. This diagram explains the example architecture:
 
-.. figure:: /figures/Storage_Object.png
+.. figure:: figures/Storage_Object.png
 
 The example REST interface, presented as a traditional Object store
 running on traditional spindles, does not require a high performance
@@ -67,7 +67,7 @@ OpenStack has integration with Hadoop to manage the Hadoop cluster
 within the cloud. The following diagram shows an OpenStack store with a
 high performance requirement:
 
-.. figure:: /figures/Storage_Hadoop3.png
+.. figure:: figures/Storage_Hadoop3.png
 
 The hardware requirements and configuration are similar to those of the
 High Performance Database example below. In this case, the architecture
@@ -95,7 +95,7 @@ database example below, a portion of the SSD pool can act as a block
 device to the Database server. In the high performance analytics
 example, the inline SSD cache layer accelerates the REST interface.
 
-.. figure:: /figures/Storage_Database_+_Object5.png
+.. figure:: figures/Storage_Database_+_Object5.png
 
 In this example, Ceph presents a Swift-compatible REST interface, as
 well as a block level storage from a distributed storage cluster. It is