Merge "doc: Populate the 'reference' section"

doc/source/api_microversion_history.rst

@@ -1 +0,0 @@
-.. include:: ../../nova/api/openstack/compute/rest_api_version_history.rst

doc/source/architecture.rst

@@ -32,7 +32,7 @@ a `manager` that is listening for `RPC` messages.
 The one major exception is nova-compute, where a single process runs on the
 hypervisor it is managing (except when using the VMware or Ironic drivers).
 The manager also, optionally, has periodic tasks.
-For more details on our `RPC` system, please see: :doc:`rpc`
+For more details on our `RPC` system, please see: :doc:`/reference/rpc`
 
 Nova also uses a central database that is (logically) shared between all
 components. However, to aid upgrade, the DB is accessed through an object

doc/source/contributor/code-review.rst

@@ -243,7 +243,7 @@ Notifications
 =============
 
 * Every new notification type shall use the new versioned notification
-  infrastructure documented in :doc:`/notifications`
+  infrastructure documented in :doc:`/reference/notifications`
 
 Release Notes
 =============

doc/source/index.rst

@@ -54,7 +54,7 @@ forward. You can also see a history of our microversions here:
 .. toctree::
    :maxdepth: 1
 
-   api_microversion_history
+   reference/api-microversion-history
 
 .. note::
     Only Version 2.1 APIs should be used from this point forward, Version 2.0
@@ -147,18 +147,18 @@ Open Development.
    :maxdepth: 1
 
    contributor/api-2
-   rpc
+   reference/rpc
    block_device_mapping
    conductor
    filter_scheduler
    aggregates
-   i18n
-   notifications
+   reference/i18n
+   reference/notifications
    placement
    contributor/placement
    quotas
-   threading
-   vmstates
+   reference/threading
+   reference/vm-states
    wsgi
 
 Architecture Evolution Plans
@@ -178,9 +178,9 @@ these are a great place to start reading up on the current plans.
    upgrade
    contributor/api
    contributor/microversions
-   policy_enforcement
-   stable_api
-   scheduler_evolution
+   reference/policy-enforcement
+   reference/stable-api
+   reference/scheduler-evolution
 
 Advanced testing and guides
 ----------------------------
@@ -188,7 +188,7 @@ Advanced testing and guides
 .. toctree::
     :maxdepth: 1
 
-    gmr
+    reference/gmr
     contributor/testing/libvirt-numa
     contributor/testing/serial-console
     contributor/testing/zero-downtime-upgrade
@@ -222,7 +222,7 @@ Module Reference
 .. toctree::
    :maxdepth: 1
 
-   services
+   reference/services
 
 
 .. # NOTE(mriedem): This is the section where we hide things that we don't

doc/source/reference/api-microversion-history.rst

@@ -0,0 +1 @@
+.. include:: ../../../nova/api/openstack/compute/rest_api_version_history.rst

doc/source/reference/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:: /_static/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:: /_static/images/rpc-rabt.png
    :width: 60%
 
 ..
@@ -62,7 +62,7 @@ The diagram below shows the message flow during an rpc.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:: /_static/images/rpc-flow-1.png
    :width: 60%
 
 ..
@@ -75,7 +75,7 @@ The diagram below shows the message flow during an rpc.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:: /_static/images/rpc-flow-2.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:: /_static/images/rpc-state.png
    :width: 60%
 
 ..

doc/source/reference/vm-states.rst

@@ -136,6 +136,6 @@ Create Instance States
 The following diagram shows the sequence of VM states, task states, and
 power states when a new VM instance is created.
 
-.. image:: ./images/create_vm_states.svg
+.. image:: /_static/images/create-vm-states.svg
    :alt: Sequence of VM states, task states, and power states when a new
          VM instance is created.