Merge "Fix the uris in documentation"

doc/source/devref/filter_scheduler.rst

@@ -8,7 +8,7 @@ only working with Compute Nodes.
 Filtering
 ---------
 
-.. image:: /images/filteringWorkflow1.png
+.. image:: ../images/filteringWorkflow1.png
 
 During its work Filter Scheduler firstly makes dictionary of unfiltered hosts,
 then filters them using filter properties and finally chooses hosts for the
@@ -375,7 +375,7 @@ so subsequent selections can adjust accordingly. It is useful if the customer
 asks for the some large amount of instances, because weight is computed for
 each instance requested.
 
-.. image:: /images/filteringWorkflow2.png
+.. image:: ../images/filteringWorkflow2.png
 
 In the end Filter Scheduler sorts selected hosts by their weight and provisions
 instances on them.

doc/source/devref/rpc.rst

@@ -25,7 +25,7 @@ AMQP is the messaging technology chosen by the OpenStack cloud.  The AMQP broker
 
 Nova uses direct, fanout, and topic-based exchanges. The architecture looks like the one depicted in the figure below:
 
-.. image:: /images/rpc/arch.png
+.. image:: ../images/rpc/arch.png
    :width: 60%
 
 ..
@@ -47,7 +47,7 @@ Figure 2 shows the following internal elements:
     * Direct Exchange: this is a routing table that is created during rpc.call operations; there are many instances of this kind of exchange throughout the life-cycle of a message broker node, one for each rpc.call invoked.
     * Queue Element: A Queue is a message bucket. Messages are kept in the queue until a Consumer (either Topic or Direct Consumer) connects to the queue and fetch it. Queues can be shared or can be exclusive. Queues whose routing key is 'topic' are shared amongst Workers of the same personality.
 
-.. image:: /images/rpc/rabt.png
+.. image:: ../images/rpc/rabt.png
    :width: 60%
 
 ..
@@ -62,7 +62,7 @@ The diagram below shows the message flow during an rp.call operation:
     3. once the task is completed, a Direct Publisher is allocated to send the response message to the queuing system.
     4. once the message is dispatched by the exchange, it is fetched by the Direct Consumer dictated by the routing key (such as 'msg_id') and passed to the Invoker.
 
-.. image:: /images/rpc/flow1.png
+.. image:: ../images/rpc/flow1.png
    :width: 60%
 
 ..
@@ -75,7 +75,7 @@ The diagram below the message flow during an rp.cast operation:
     1. A Topic Publisher is instantiated to send the message request to the queuing system.
     2. Once the message is dispatched by the exchange, it is fetched by the Topic Consumer dictated by the routing key (such as 'topic') and passed to the Worker in charge of the task.
 
-.. image:: /images/rpc/flow2.png
+.. image:: ../images/rpc/flow2.png
    :width: 60%
 
 ..
@@ -100,7 +100,7 @@ The figure below shows the status of a RabbitMQ node after Nova components' boot
        5. scheduler.phantom (phantom is hostname)
        6. scheduler
 
-.. image:: /images/rpc/state.png
+.. image:: ../images/rpc/state.png
    :width: 60%
 
 ..

doc/source/devref/vmstates.rst

@@ -150,9 +150,9 @@ task states for various commands issued by the user:
     active -> live_migrate
   }
 
-.. image:: /images/PowerStates1.png
+.. image:: ../images/PowerStates1.png
 
-.. image:: /images/PowerStates2.png
+.. image:: ../images/PowerStates2.png
 
 
 Create instance states
@@ -162,4 +162,4 @@ The following diagram shows the sequence of VM states, task states, and
 power states when a new VM instance is created.
 
 
-.. image:: /images/run_instance_walkthrough.png
+.. image:: ../images/run_instance_walkthrough.png