Merge "This patch is used to update the documents of D-release."

7 files changed, 130 insertions, 44 deletions

diff --git a/docs/configurationguide/abstract.rst b/docs/configurationguide/abstract.rst
index a5066c284..3693bcab7 100644
--- a/docs/configurationguide/abstract.rst
+++ b/docs/configurationguide/abstract.rst
@@ -1,12 +1,12 @@
 .. This work is licensed under a Creative Commons Attribution 4.0 International License.
 .. http://creativecommons.org/licenses/by/4.0
 
-========
-Abstract
-========
+======================
+Configuration Abstract
+======================
 
 This document provides guidance for the configurations available in the
-Colorado release of OPNFV.
+Danube release of OPNFV
 
 The release includes four installer tools leveraging different technologies;
 Apex, Compass4nfv, Fuel and JOID, which deploy components of the platform.
diff --git a/docs/configurationguide/configuration.options.render.rst b/docs/configurationguide/configuration.options.render.rst
index 93add7755..1c1c62228 100644
--- a/docs/configurationguide/configuration.options.render.rst
+++ b/docs/configurationguide/configuration.options.render.rst
@@ -13,11 +13,11 @@ such as OpenStack,KVM etc. which includes different source components or
 configurations.
 
 KVM4NFV Scenarios
-===================
+------------------
 
 Each KVM4NFV scenario provides unique features and capabilities, it is
 important to understand your target platform capabilities before installing
 and configuring. This configuration guide outlines how to install and
 configure components in order to enable the features required.
 
-.. include:: scenariomatrix.rst
+.. include:: ./scenariomatrix.rst
diff --git a/docs/configurationguide/images/idle-idle-test.png b/docs/configurationguide/images/idle-idle-test.png
new file mode 100644
index 000000000..c9831df1d
--- /dev/null
+++ b/docs/configurationguide/images/idle-idle-test.png
diff --git a/docs/configurationguide/images/stress-idle-test.png b/docs/configurationguide/images/stress-idle-test.png
new file mode 100644
index 000000000..111c2a7d2
--- /dev/null
+++ b/docs/configurationguide/images/stress-idle-test.png
diff --git a/docs/configurationguide/index.rst b/docs/configurationguide/index.rst
index 6ad3b282c..b4cb69839 100644
--- a/docs/configurationguide/index.rst
+++ b/docs/configurationguide/index.rst
@@ -4,7 +4,7 @@
 *************************
 OPNFV Configuration Guide
 *************************
-Colorado 1.0
+Danube 1.0
 ------------
 
 .. toctree::
diff --git a/docs/configurationguide/low-latency.feature.configuration.description.rst b/docs/configurationguide/low-latency.feature.configuration.description.rst
index bf2dbdb44..6cad4c9ce 100644
--- a/docs/configurationguide/low-latency.feature.configuration.description.rst
+++ b/docs/configurationguide/low-latency.feature.configuration.description.rst
@@ -1,9 +1,12 @@
 .. This work is licensed under a Creative Commons Attribution 4.0 International License.
 .. http://creativecommons.org/licenses/by/4.0
 
-Introduction
-============
+=============================================
+Low Latency Feature Configuration Description
+=============================================
 
+Introduction
+------------
 In KVM4NFV project, we focus on the KVM hypervisor to enhance it for NFV, by
 looking at the following areas initially
 
@@ -14,7 +17,7 @@ looking at the following areas initially
 * Fast live migration
 
 Configuration of Cyclictest
-===========================
+---------------------------
 
 Cyclictest measures Latency of response to a stimulus. Achieving low latency
 with the KVM4NFV project requires setting up a special test environment.
@@ -26,15 +29,56 @@ parameters and the run-time environment.
   https://wiki.opnfv.org/display/kvm/Nfv-kvm-tuning
 
 Pre-configuration activities
-----------------------------
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Intel POD10 is currently used as OPNFV-KVM4NFV test environment. The rpm
+packages from the latest build are downloaded onto Intel-Pod10 jump server
+from artifact repository. Yardstick running in a ubuntu docker container
+on Intel Pod10-jump server will configure the host(intel pod10 node1/node2
+based on job type), the guest and triggers the cyclictest on the guest using
+below sample yaml file.
+
+
+.. code:: bash
+
+    For IDLE-IDLE test,
+
+    host_setup_seqs:
+    - "host-setup0.sh"
+    - "reboot"
+    - "host-setup1.sh"
+    - "host-run-qemu.sh"
+
+    guest_setup_seqs:
+    - "guest-setup0.sh"
+    - "reboot"
+    - "guest-setup1.sh"
 
-Intel POD1 is currently used as OPNFV-KVM4NFV test environment. The latest
-build packages are downloaded onto Intel Pod1-jump server from artifact
-repository. Yardstick running in a ubuntu docker container on Intel Pod1-jump
-server will trigger the cyclictest.
+.. figure:: images/idle-idle-test.png
+   :name: idle-idle-test
+   :width: 100%
+   :align: center
 
-Running cyclictest through Yardstick will Configure the host(Pod1-node1), the
-guest, executes  cyclictest on the guest.
+.. code:: bash
+
+    For [CPU/Memory/IO]Stress-IDLE tests,
+
+    host_setup_seqs:
+    - "host-setup0.sh"
+    - "reboot"
+    - "host-setup1.sh"
+    - "stress_daily.sh" [cpustress/memory/io]
+    - "host-run-qemu.sh"
+
+    guest_setup_seqs:
+    - "guest-setup0.sh"
+    - "reboot"
+    - "guest-setup1.sh"
+
+.. figure:: images/stress-idle-test.png
+   :name: stress-idle-test
+   :width: 100%
+   :align: center
 
 The following scripts are used for configuring host and guest to create a
 special test environment and achieve low latency.
@@ -44,7 +88,7 @@ followed by guest-setup0.sh and guest-setup1.sh scripts on the guest VM.
 
 **host-setup0.sh**: Running this script will install the latest kernel rpm
 on host and will make necessary changes as following to create special test
-environment
+environment.
 
    * Isolates CPUs from the general scheduler
    * Stops timer ticks on isolated CPUs whenever possible
@@ -55,15 +99,28 @@ environment
    * Disables clocksource verification at runtime
 
 **host-setup1.sh**: Running this script will make the following test
-environment changes
+environment changes.
 
    * Disabling watchdogs to reduce overhead
    * Disabling RT throttling
    * Reroute interrupts bound to isolated CPUs to CPU 0
    * Change the iptable so that we can ssh to the guest remotely
 
+**stress_daily.sh**: Scripts gets triggered only for stress-idle tests. Running this script
+make the following environment changes.
+
+   * Triggers stress_script.sh, which runs the stress command with necessary options
+   * CPU,Memory or IO stress can be applied based on the test type
+   * Applying stress only on the Host is handled in D-Release
+   * For Idle-Idle test the stress script is not triggered
+   * Stress is applied only on the free cores to prevent load on qemu process
+
+   **Note:**
+    - On Numa Node 1: 22,23 cores are allocated for QEMU process
+    - 24-43 are used for applying stress
+
 **host-run-qemu.sh**: Running this script will launch a guest vm on the host.
-     Note: download guest disk image from artifactory
+     Note: download guest disk image from artifactory.
 
 **guest-setup0.sh**: Running this scrcipt on the guest vm will install the
 latest build kernel rpm, cyclictest and make the following configuration on
@@ -75,22 +132,22 @@ guest vm.
    * Disables clocksource verification at runtime
 
 **guest-setup1.sh**: Running this script on guest vm will do the following
-configurations
+configurations.
 
    * Disable watchdogs to reduce overhead
    * Routes device interrupts to non-RT CPU
    * Disables RT throttling
 
 Hardware configuration
-----------------------
+~~~~~~~~~~~~~~~~~~~~~~
 
-Currently Intel POD1 is used as test environment for kvmfornfv to execute
-cyclictest. As part of this test environment Intel pod1-jump is configured as
+Currently Intel POD10 is used as test environment for kvmfornfv to execute
+cyclictest. As part of this test environment Intel pod10-jump is configured as
 jenkins slave and all the latest build artifacts are downloaded on to it.
-Intel pod1-node1 is the host on which a guest vm will be launched as a part of
+Intel pod10-node1 is the host on which a guest vm will be launched as a part of
 running cylictest through yardstick.
 
 * For more information regarding hardware configuration, please visit
-  https://wiki.opnfv.org/display/pharos/Intel+Pod1
-  https://build.opnfv.org/ci/computer/intel-pod1/
+  https://wiki.opnfv.org/display/pharos/Intel+Pod10
+  https://build.opnfv.org/ci/computer/intel-pod10/
   http://artifacts.opnfv.org/octopus/brahmaputra/docs/octopus_docs/opnfv-jenkins-slave-connection.html
diff --git a/docs/configurationguide/scenariomatrix.rst b/docs/configurationguide/scenariomatrix.rst
index 1e2cef90a..3da38ed60 100644
--- a/docs/configurationguide/scenariomatrix.rst
+++ b/docs/configurationguide/scenariomatrix.rst
@@ -2,17 +2,21 @@
 
 .. http://creativecommons.org/licenses/by/4.0
 
+==============
+Scenariomatrix
+==============
+
 Scenarios are implemented as deployable compositions through integration with an installation tool.
 OPNFV supports multiple installation tools and for any given release not all tools will support all
 scenarios. While our target is to establish parity across the installation tools to ensure they
 can provide all scenarios, the practical challenge of achieving that goal for any given feature and
 release results in some disparity.
 
-Colorado scenario overeview
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+Danube scenario overeview
+^^^^^^^^^^^^^^^^^^^^^^^^^
 
 The following table provides an overview of the installation tools and available scenario's
-in the Colorado release of OPNFV.
+in the Danube release of OPNFV.
 
 Scenario status is indicated by a weather pattern icon. All scenarios listed with
 a weather pattern are possible to deploy and run in your environment or a Pharos lab,
@@ -23,17 +27,17 @@ Weather pattern icon legend:
 +---------------------------------------------+----------------------------------------------------------+
 | Weather Icon                                | Scenario Status                                          |
 +=============================================+==========================================================+
-| .. image:: ../images/weather-clear.jpg      | Stable, no known issues                                  |
+| .. image:: images/weather-clear.jpg         | Stable, no known issues                                  |
 +---------------------------------------------+----------------------------------------------------------+
-| .. image:: ../images/weather-few-clouds.jpg | Stable, documented limitations                           |
+| .. image:: images/weather-few-clouds.jpg    | Stable, documented limitations                           |
 +---------------------------------------------+----------------------------------------------------------+
-| .. image:: ../images/weather-overcast.jpg   | Deployable, stability or feature limitations             |
+| .. image:: images/weather-overcast.jpg      | Deployable, stability or feature limitations             |
 +---------------------------------------------+----------------------------------------------------------+
-| .. image:: ../images/weather-dash.jpg       | Not deployed with this installer                         |
+| .. image:: images/weather-dash.jpg          | Not deployed with this installer                         |
 +---------------------------------------------+----------------------------------------------------------+
 
 Scenarios that are not yet in a state of "Stable, no known issues" will continue to be stabilised
-and updates will be made on the stable/colorado branch. While we intend that all Colorado
+and updates will be made on the stable/danube branch. While we intend that all Danube
 scenarios should be stable it is worth checking regularly to see the current status.  Due to
 our dependency on upstream communities and code some issues may not be resolved prior to the D release.
 
@@ -43,48 +47,73 @@ Scenario Naming
 In OPNFV scenarios are identified by short scenario names, these names follow a scheme that
 identifies the key components and behaviours of the scenario. The rules for scenario naming are as follows:
 
+.. code:: bash
+
   os-[controller]-[feature]-[mode]-[option]
 
 Details of the fields are
-  * os: mandatory
+
+  * **[os]:** mandatory
 
     * Refers to the platform type used
     * possible value: os (OpenStack)
 
-* [controller]: mandatory
+  * **[controller]:** mandatory
 
     * Refers to the SDN controller integrated in the platform
     * example values: nosdn, ocl, odl, onos
 
-  * [feature]: mandatory
+  * **[feature]:** mandatory
 
     * Refers to the feature projects supported by the scenario
     * example values: nofeature, kvm, ovs, sfc
 
-  * [mode]: mandatory
+  * **[mode]:** mandatory
 
     * Refers to the deployment type, which may include for instance high availability
     * possible values: ha, noha
 
-  * [option]: optional
+  * **[option]:** optional
 
     * Used for the scenarios those do not fit into naming scheme.
     * The optional field in the short scenario name should not be included if there is no optional scenario.
 
 Some examples of supported scenario names are:
 
-  * os-nosdn-kvm-noha
+  * **os-nosdn-kvm-noha**
 
     * This is an OpenStack based deployment using neutron including the OPNFV enhanced KVM hypervisor
 
-  * os-onos-nofeature-ha
+  * **os-onos-nofeature-ha**
 
     * This is an OpenStack deployment in high availability mode including ONOS as the SDN controller
 
-  * os-odl_l2-sfc
+  * **os-odl_l2-sfc**
 
     * This is an OpenStack deployment using OpenDaylight and OVS enabled with SFC features
 
+  * **os-nosdn-kvm_nfv_ovs_dpdk-ha**
+
+    * This is an Openstack deployment with high availability using OVS, DPDK including the OPNFV enhanced KVM hypervisor
+    * This deployment has ``3-Contoller and 2-Compute nodes``
+
+  * **os-nosdn-kvm_nfv_ovs_dpdk-noha**
+
+    * This is an Openstack deployment without high availability using OVS, DPDK including the OPNFV enhanced KVM hypervisor
+    * This deployment has ``1-Contoller and 3-Compute nodes``
+
+  * **os-nosdn-kvm_nfv_ovs_dpdk_bar-ha**
+
+    * This is an Openstack deployment with high availability using OVS, DPDK including the OPNFV enhanced KVM hypervisor
+      and Barometer
+    * This deployment has ``3-Contoller and 2-Compute nodes``
+
+  * **os-nosdn-kvm_nfv_ovs_dpdk_bar-noha**
+
+    * This is an Openstack deployment without high availability using OVS, DPDK including the OPNFV enhanced KVM hypervisor
+      and Barometer
+    * This deployment has ``1-Contoller and 3-Compute nodes``
+
 Installing your scenario
 ^^^^^^^^^^^^^^^^^^^^^^^^
 
@@ -92,7 +121,7 @@ There are two main methods of deploying your target scenario, one method is to f
 walk you through the process of deploying to your hardware using scripts or ISO images, the other method is
 to set up a Jenkins slave and connect your infrastructure to the OPNFV Jenkins master.
 
-For the purposes of evaluation and development a number of Colorado scenarios are able to be deployed
+For the purposes of evaluation and development a number of Danube scenarios are able to be deployed
 virtually to mitigate the requirements on physical infrastructure. Details and instructions on performing
 virtual deployments can be found in the installer specific installation instructions.