Fix side menu depth

Change-Id: I112ee28f032b4ead9f1cbd67b3d18f357e54d7b6

doc/source/benchmark.rst

@@ -19,16 +19,16 @@ Benchmark
 =========
 
 Benchmark Scenarios
-===================
+-------------------
 
 Notion of benchmark scenarios
------------------------------
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 The concept of **benchmark scenarios** is a central one in Rally. Benchmark scenarios are what Rally actually uses to **test the performance of an OpenStack deployment**. They also play the role of main building blocks in the configurations of benchmark tasks. Each benchmark scenario performs a small **set of atomic operations**, thus testing some **simple use case**, usually that of a specific OpenStack project. For example, the **"NovaServers"** scenario group contains scenarios that use several basic operations available in **nova**. The **"boot_and_delete_server"** benchmark scenario from that group allows to benchmark the performance of a sequence of only **two simple operations**: it first **boots** a server (with customizable parameters) and then **deletes** it.
 
 
 User's view
------------
+^^^^^^^^^^^
 
 From user's point of view, Rally launches different benchmark scenarios while performing some benchmark task. **Benchmark task** is essentially a set of benchmark scenarios run against some OpenStack deployment in a specific (and customizable) manner by the CLI command:
 
@@ -75,7 +75,7 @@ Note that inside each scenario configuration, the benchmark scenario is actually
 
 
 Developer's  view
------------------
+^^^^^^^^^^^^^^^^^
 
 From developer's prospective, a benchmark scenario is a method marked by a **@scenario** decorator and placed in a class that inherits from the base `Scenario <https://github.com/stackforge/rally/blob/master/rally/benchmark/scenarios/base.py#L40>`_ class and located in some subpackage of `rally.benchmark.scenarios <https://github.com/stackforge/rally/tree/master/rally/benchmark/scenarios>`_. There may be arbitrary many benchmark scenarios in a scenario class; each of them should be referenced to (in the task configuration file) as *ScenarioClassName.method_name*.
 
@@ -106,19 +106,19 @@ In a toy example below, we define a scenario class *MyScenario* with one benchma
 
 
 Benchmark engine
-================
+----------------
 
 The core classes responsible for the benchmarking mechanism, including
 the benchmark engine class, benchmark scenario runners and others.
 
 Notion of scenario runners
---------------------------
+^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 **Scenario Runners** in Rally are entities that control the execution type and order of benchmark scenarios. They support different running **strategies for creating load on the cloud**, including simulating *concurrent requests* from different users, periodic load, gradually growing load and so on.
 
 
 User's view
------------
+^^^^^^^^^^^
 
 The user can specify which type of load on the cloud he would like to have through the **"runner"** section in the **task configuration file**:
 
@@ -164,7 +164,7 @@ Also, all scenario runners can be provided (again, through the **"runner"** sect
 
 
 Developer's  view
------------------
+^^^^^^^^^^^^^^^^^
 
 It is possible to extend Rally with new Scenario Runner types, if needed. Basically, each scenario runner should be implemented as a subclass of the base `ScenarioRunner <https://github.com/stackforge/rally/blob/master/rally/benchmark/runners/base.py#L137>`_ class and located in the `rally.benchmark.runners package <https://github.com/stackforge/rally/tree/master/rally/benchmark/runners>`_. The interface each scenario runner class should support is fairly easy:
 
@@ -212,16 +212,16 @@ It is possible to extend Rally with new Scenario Runner types, if needed. Basica
 
 
 Benchmark contexts
-==================
+------------------
 
 Notion of contexts
-------------------
+^^^^^^^^^^^^^^^^^^
 
 The notion of **contexts** in Rally is essentially used to define different types of **environments** in which benchmark scenarios can be launched. Those environments are usually specified by such parameters as the number of **tenants and users** that should be present in an OpenStack project, the **roles** granted to those users, extended or narrowed **quotas** and so on.
 
 
 User's view
------------
+^^^^^^^^^^^
 
 From user's prospective, contexts in Rally are manageable via the **task configuration files**. In a typical configuration file, each benchmark scenario to be run is not only supplied by the information about its arguments and how many times it should be launched, but also with a special **"context"** section. In this section, the user may configure a number of contexts he needs his scenarios to be run within.
 
@@ -258,7 +258,7 @@ In the example below, the **"users" context** specifies that the *"NovaServers.b
 
 
 Developer's view
-----------------
+^^^^^^^^^^^^^^^^
 
 From developer's view, contexts management is implemented via **Context classes**. Each context type that can be specified in the task configuration file corresponds to a certain subclass of the base [https://github.com/stackforge/rally/blob/master/rally/benchmark/context/base.py **Context**] class, located in the [https://github.com/stackforge/rally/tree/master/rally/benchmark/context **rally.benchmark.context**] module. Every context class should implement a fairly simple **interface**:
 
@@ -320,23 +320,23 @@ If you want to dive deeper, also see the context manager (:mod:`rally.benchmark.
 
 
 Scenarios Plugins
-=================
+-----------------
 
 Rally provides an opportunity to create and use a custom benchmark scenario as
 a plugin. The plugins mechanism can be used to simplify some experiments with
 new scenarios and to facilitate their creation by users who don't want to edit
 the actual Rally code.
 
 Placement
----------
+^^^^^^^^^
 
 Put the plugin into the **/etc/rally/plugins/scenarios** or
 **~/.rally/plugins/scenarios** directory and it will be autoloaded (they are
 not created automatically, you should create them manually). The corresponding
 module should have ".py" extension.
 
 Creation
---------
+^^^^^^^^
 
 Inherit a class containing the scenario method(s) from
 `rally.benchmark.scenarios.base.Scenario` or its subclasses.
@@ -377,7 +377,7 @@ benchmark scenario results have been stored correctly.
             self._test2(factor)
 
 Usage
------
+^^^^^
 
 Specify the class and the benchmark method of your plugin at the top level of
 the benchmark task configuration file.

doc/source/deploy.rst

@@ -19,7 +19,7 @@ Deploy
 ======
 
 Deployment engines
-==================
+------------------
 
 One of the core entities in Rally architecture are the **Deploy engines**. The main task of a deploy engine is to control the process of **deploying some OpenStack distribution** like *DevStack* or *FUEL* before any benchmarking procedures take place. Every deploy engine should implement the following fairly simple interface:
 
@@ -30,7 +30,7 @@ One of the core entities in Rally architecture are the **Deploy engines**. The m
 
 
 Server Providers
-================
+----------------
 
 **Server providers** in Rally are typically used by **deploy engines** to manage virtual machines necessary for OpenStack deployment and its following benchmarking. The key feature of server providers is that they provide a **unified interface** for interacting with different **virtualization technologies** (*LXS*, *Virsh* etc.) and **cloud suppliers** (like *Amazon*).
 

doc/source/implementation.rst

@@ -20,7 +20,7 @@ Implementation
 
 
 Benchmark engine
-================
+----------------
 
 The :mod:`rally.benchmark.engine` Module
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -56,7 +56,7 @@ The :mod:`rally.benchmark.processing` Module
 
 
 Benchmark scenarios
-===================
+-------------------
 
 The :mod:`rally.benchmark.scenarios.utils` Module
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -67,7 +67,7 @@ The :mod:`rally.benchmark.scenarios.utils` Module
     :show-inheritance:
 
 The Cinder Scenarios
---------------------
+^^^^^^^^^^^^^^^^^^^^
 
 The :mod:`rally.benchmark.scenarios.cinder.volumes` Module
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -86,7 +86,7 @@ The :mod:`rally.benchmark.scenarios.cinder.utils` Module
     :show-inheritance:
 
 The Keystone Scenarios
-----------------------
+^^^^^^^^^^^^^^^^^^^^^^
 
 The :mod:`rally.benchmark.scenarios.keystone.basic` Module
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -105,7 +105,7 @@ The :mod:`rally.benchmark.scenarios.keystone.utils` Module
     :show-inheritance:
 
 The Nova Scenarios
-------------------
+^^^^^^^^^^^^^^^^^^
 
 The :mod:`rally.benchmark.scenarios.nova.servers` Module
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -126,18 +126,18 @@ The :mod:`rally.benchmark.scenarios.nova.utils` Module
 
 
 Deploy engines
-==============
+--------------
 
 The :mod:`rally.deploy.engine` Module
--------------------------------------
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 .. automodule:: rally.deploy.engine
     :members:
     :undoc-members:
     :show-inheritance:
 
 The DevStack Engine
--------------------
+^^^^^^^^^^^^^^^^^^^
 
 The :mod:`rally.deploy.engines.devstack` Module
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -148,7 +148,7 @@ The :mod:`rally.deploy.engines.devstack` Module
     :show-inheritance:
 
 The Dummy Engine
-----------------
+^^^^^^^^^^^^^^^^
 
 The :mod:`rally.deploy.engines.existing` Module
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -160,7 +160,7 @@ The :mod:`rally.deploy.engines.existing` Module
 
 
 Database
-========
+--------
 
 Represents a high level database abstraction interface which is used as persistent
 storage for Rally. The storage operations implemented in driver abstractions.
@@ -174,7 +174,7 @@ The :mod:`rally.db.api` Module
     :show-inheritance:
 
 The SQLAlchemy Driver
----------------------
+^^^^^^^^^^^^^^^^^^^^^
 
 The driver uses the sqlalchemy library and provides flexible range of supported
  SQL storages.
@@ -197,7 +197,7 @@ The :mod:`rally.db.sqlalchemy.models` Module
 
 
 Server providers
-================
+----------------
 
 The :mod:`rally.deploy.serverprovider.provider` Module
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -208,7 +208,7 @@ The :mod:`rally.deploy.serverprovider.provider` Module
     :show-inheritance:
 
 The Dummy Server Provider
--------------------------
+^^^^^^^^^^^^^^^^^^^^^^^^^
 
 The :mod:`rally.deploy.serverprovider.providers.dummy` Module
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -219,7 +219,7 @@ The :mod:`rally.deploy.serverprovider.providers.dummy` Module
     :show-inheritance:
 
 The OpenStack Server Provider
------------------------------
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 The :mod:`rally.deploy.serverprovider.providers.openstack` Module
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -230,7 +230,7 @@ The :mod:`rally.deploy.serverprovider.providers.openstack` Module
     :show-inheritance:
 
 The LXC Server Provider
------------------------
+^^^^^^^^^^^^^^^^^^^^^^^
 
 The :mod:`rally.deploy.serverprovider.providers.lxc` Module
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -241,7 +241,7 @@ The :mod:`rally.deploy.serverprovider.providers.lxc` Module
     :show-inheritance:
 
 The Virsh Server Provider
--------------------------
+^^^^^^^^^^^^^^^^^^^^^^^^^
 
 The :mod:`rally.deploy.serverprovider.providers.virsh` Module
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -253,7 +253,7 @@ The :mod:`rally.deploy.serverprovider.providers.virsh` Module
 
 
 Objects
-=======
+-------
 
 Represents a high level abstraction of persistent database objects and
 operations on them.
@@ -276,7 +276,7 @@ The :mod:`rally.objects.deploy` Module
 
 
 OpenStack Clients
-=================
+-----------------
 
 The :mod:`rally.osclients` Module
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

doc/source/index.rst

@@ -21,7 +21,7 @@ specific, complex and reproducible tests for real deployment scenarios.
 
 
 Source Documentation
-====================
+--------------------
 
 Contents:
 
@@ -36,7 +36,7 @@ Contents:
 
 
 Indices and tables
-==================
+------------------
 
 * :ref:`genindex`
 * :ref:`modindex`