doc: Populate the 'user' section

Per the spec [1]:

  user/ – end-user content such as concept guides, advice, tutorials,
  step-by-step instructions for using the CLI to perform specific tasks,
  etc.

The remaining content all ends up in here.

[1] specs.openstack.org/openstack/docs-specs/specs/pike/os-manuals-migration

Change-Id: I480eee9cd7568efe2f76dd185004774588eb4a99

doc/source/contributor/placement.rst

@@ -18,16 +18,17 @@
 Overview
 ========
 
-The Nova project introduced the :doc:`placement service </placement>` as part
+The Nova project introduced the :doc:`placement service </user/placement>` as
-of the Newton release. The service provides an HTTP API to manage inventories
+part of the Newton release. The service provides an HTTP API to manage
-of different classes of resources, such as disk or virtual cpus, made available
+inventories of different classes of resources, such as disk or virtual cpus,
-by entities called resource providers. Information provided through the
+made available by entities called resource providers. Information provided
-placement API is intended to enable more effective accounting of resources in
+through the placement API is intended to enable more effective accounting of
-an OpenStack deployment and better scheduling of various entities in the cloud.
+resources in an OpenStack deployment and better scheduling of various entities
+in the cloud.
 
 The document serves to explain the architecture of the system and to provide
 some guidance on how to maintain and extend the code. For more detail on why
-the system was created and how it does its job see :doc:`/placement`.
+the system was created and how it does its job see :doc:`/user/placement`.
 
 Big Picture
 ===========
@@ -132,8 +133,8 @@ Microversions
 =============
 
 The placement API makes use of `microversions`_ to allow the release of new
-features on an opt in basis. See :doc:`/placement` for an up to date history of
+features on an opt in basis. See :doc:`/user/placement` for an up to date
-the available microversions.
+history of the available microversions.
 
 The rules around when a microversion is needed are the same as for the
 :doc:`compute API </contributor/microversions>`. When adding a new microversion

doc/source/contributor/testing.rst

@@ -26,8 +26,8 @@ features working across upgrades, we must aim to test all features.
 Reporting Test Coverage
 =======================
 
-For details on plans to report the current test coverage, please see:
+For details on plans to report the current test coverage, refer to
-:doc:`/feature_classification`
+:doc:`/user/feature-classification`.
 
 Running tests and reporting results
 ===================================

doc/source/index.rst

@@ -86,8 +86,8 @@ integration testing efforts.
    :maxdepth: 1
 
    contributor/testing
-   feature_classification
+   user/feature-classification
-   support-matrix
+   user/support-matrix
 
 Developer Guide
 ===============
@@ -100,7 +100,7 @@ actually does, and why.
 
    contributor/how-to-get-involved
    contributor/process
-   architecture
+   user/architecture
    contributor/project-scope
    contributor/development-environment
 
@@ -148,18 +148,18 @@ Open Development.
 
    contributor/api-2
    reference/rpc
-   block_device_mapping
+   user/block-device-mapping
-   conductor
+   user/conductor
-   filter_scheduler
+   user/filter-scheduler
-   aggregates
+   user/aggregates
    reference/i18n
    reference/notifications
-   placement
+   user/placement
    contributor/placement
-   quotas
+   user/quotas
    reference/threading
    reference/vm-states
-   wsgi
+   user/wsgi
 
 Architecture Evolution Plans
 -----------------------------
@@ -174,8 +174,8 @@ these are a great place to start reading up on the current plans.
 .. toctree::
    :maxdepth: 1
 
-   cells
+   user/cells
-   upgrade
+   user/upgrade
    contributor/api
    contributor/microversions
    reference/policy-enforcement
@@ -238,7 +238,7 @@ Metadata
 .. toctree::
     :maxdepth: 1
 
-    vendordata
+    user/vendordata
 
 Indices and tables
 ==================

doc/source/user/architecture.rst

@@ -50,7 +50,7 @@ Components
 Below you will find a helpful explanation of the key components
 of a typical (non-cells v1) Nova deployment.
 
-.. image:: ./images/architecture.svg
+.. image:: /_static/images/architecture.svg
    :width: 100%
 
 * DB: sql database for data storage.

doc/source/user/feature-classification.rst

@@ -52,7 +52,7 @@ Below there are sections on NFV and HPC specific features. These look at
 specific features and scenarios that are important to those more specific
 sets of use cases.
 
-.. feature_matrix:: feature_matrix_gp.ini
+.. feature_matrix:: feature-matrix-gp.ini
 
 .. _matrix-nfv:
 
@@ -65,7 +65,7 @@ create a particular service. It is common for this workloads needing
 bare metal like performance, i.e. low latency and close to line speed
 performance.
 
-.. feature_matrix:: feature_matrix_nfv.ini
+.. feature_matrix:: feature-matrix-nfv.ini
 
 .. _matrix-hpc:
 
@@ -75,7 +75,7 @@ HPC Cloud Features
 High Performance Compute (HPC) cloud have some specific needs that are covered
 in this set of features.
 
-.. feature_matrix:: feature_matrix_hpc.ini
+.. feature_matrix:: feature-matrix-hpc.ini
 
 .. _notes-on-concepts:
 

doc/source/user/filter-scheduler.rst

@@ -8,7 +8,7 @@ working with Compute Nodes only.
 Filtering
 ---------
 
-.. image:: ./images/filteringWorkflow1.png
+.. image:: /_static/images/filtering-workflow-1.png
 
 During its work Filter Scheduler iterates over all found compute nodes,
 evaluating each against a set of filters. The list of resulting hosts is
@@ -470,7 +470,7 @@ so subsequent selections can adjust accordingly. It is useful if the customer
 asks for a large block of instances, because weight is computed for
 each instance requested.
 
-.. image:: ./images/filteringWorkflow2.png
+.. image:: /_static/images/filtering-workflow-2.png
 
 At the end Filter Scheduler sorts selected hosts by their weight and attempts
 to provision instances on the chosen hosts.

doc/source/user/placement.rst

@@ -227,4 +227,4 @@ nova-compute service could be Newton level code making requests to an Ocata
 placement API, and vice-versa, an Ocata compute service in a cells v2 cell
 could be making requests to a Newton placement API.
 
-.. include:: ../../nova/api/openstack/placement/rest_api_version_history.rst
+.. include:: ../../../nova/api/openstack/placement/rest_api_version_history.rst

doc/source/user/support-matrix.rst

@@ -5,7 +5,7 @@ Feature Support Matrix
 .. warning::
     Please note, while this document is still being maintained, this is slowly
     being updated to re-group and classify features using the definitions
-    described in here: :doc:`feature_classification`
+    described in here: :doc:`feature-classification`
 
 When considering which capabilities should be marked as mandatory the
 following general guiding principles were applied