From ad7ff14ce6b6a30bb9276b904c528913fa3d2808 Mon Sep 17 00:00:00 2001
From: JingLu5 <lvjing5@huawei.com>
Date: Thu, 30 Mar 2017 11:50:02 +0000
Subject: add yardstick_user_interface chapter in userguide
JIRA: YARDSTICK-618
Change-Id: I690c24d665016a381ae1ed7d8fa94d5a34bc1b1b
Signed-off-by: JingLu5 <lvjing5@huawei.com>
(cherry picked from commit 0ce79677b81b47a7f66e43af896cfa9632da6bee)
---
docs/testing/user/userguide/01-introduction.rst | 16 +-
docs/testing/user/userguide/09-vtc-overview.rst | 128 ---------
.../user/userguide/09-yardstick_user_interface.rst | 29 ++
.../user/userguide/10-apexlake_installation.rst | 302 ---------------------
docs/testing/user/userguide/10-vtc-overview.rst | 128 +++++++++
docs/testing/user/userguide/11-apexlake_api.rst | 89 ------
.../user/userguide/11-apexlake_installation.rst | 302 +++++++++++++++++++++
docs/testing/user/userguide/12-apexlake_api.rst | 89 ++++++
docs/testing/user/userguide/12-nsb-overview.rst | 194 -------------
docs/testing/user/userguide/13-nsb-overview.rst | 194 +++++++++++++
.../testing/user/userguide/13-nsb_installation.rst | 238 ----------------
docs/testing/user/userguide/14-list-of-tcs.rst | 129 ---------
.../testing/user/userguide/14-nsb_installation.rst | 238 ++++++++++++++++
docs/testing/user/userguide/15-list-of-tcs.rst | 129 +++++++++
.../user/userguide/Yardstick_user_interface.rst | 29 --
docs/testing/user/userguide/index.rst | 13 +-
16 files changed, 1126 insertions(+), 1121 deletions(-)
delete mode 100644 docs/testing/user/userguide/09-vtc-overview.rst
create mode 100644 docs/testing/user/userguide/09-yardstick_user_interface.rst
delete mode 100644 docs/testing/user/userguide/10-apexlake_installation.rst
create mode 100644 docs/testing/user/userguide/10-vtc-overview.rst
delete mode 100644 docs/testing/user/userguide/11-apexlake_api.rst
create mode 100644 docs/testing/user/userguide/11-apexlake_installation.rst
create mode 100644 docs/testing/user/userguide/12-apexlake_api.rst
delete mode 100644 docs/testing/user/userguide/12-nsb-overview.rst
create mode 100644 docs/testing/user/userguide/13-nsb-overview.rst
delete mode 100644 docs/testing/user/userguide/13-nsb_installation.rst
delete mode 100644 docs/testing/user/userguide/14-list-of-tcs.rst
create mode 100644 docs/testing/user/userguide/14-nsb_installation.rst
create mode 100644 docs/testing/user/userguide/15-list-of-tcs.rst
delete mode 100644 docs/testing/user/userguide/Yardstick_user_interface.rst
diff --git a/docs/testing/user/userguide/01-introduction.rst b/docs/testing/user/userguide/01-introduction.rst
index 4fc94ac62..63d0d9883 100755
--- a/docs/testing/user/userguide/01-introduction.rst
+++ b/docs/testing/user/userguide/01-introduction.rst
@@ -61,22 +61,26 @@ This document consists of the following chapters:
* Chapter :doc:`08-api` provides inforamtion on *Yardstick* ReST API and how to
use *Yardstick* API.
-* Chapter :doc:`09-vtc-overview` provides information on the :term:`VTC`.
+* Chapter :doc:`09-yardstick_user_interface` provides inforamtion on how to use
+ yardstick report CLI to view the test result in table format and also values
+ pinned on to a graph
-* Chapter :doc:`10-apexlake_installation` provides instructions to install the
+* Chapter :doc:`10-vtc-overview` provides information on the :term:`VTC`.
+
+* Chapter :doc:`11-apexlake_installation` provides instructions to install the
experimental framework *ApexLake*
-* Chapter :doc:`11-apexlake_api` explains how this framework is integrated in
+* Chapter :doc:`12-apexlake_api` explains how this framework is integrated in
*Yardstick*.
-* Chapter :doc:`12-nsb-overview` describes the methodology implemented by the
+* Chapter :doc:`13-nsb-overview` describes the methodology implemented by the
Yardstick - Network service benchmarking to test real world usecase for a
given VNF.
-* Chapter :doc:`13-nsb_installation` provides instructions to install
+* Chapter :doc:`14-nsb_installation` provides instructions to install
*Yardstick - Network service benchmarking testing*.
-* Chapter :doc:`14-list-of-tcs` includes a list of available *Yardstick* test
+* Chapter :doc:`15-list-of-tcs` includes a list of available *Yardstick* test
cases.
diff --git a/docs/testing/user/userguide/09-vtc-overview.rst b/docs/testing/user/userguide/09-vtc-overview.rst
deleted file mode 100644
index 8ed17873d..000000000
--- a/docs/testing/user/userguide/09-vtc-overview.rst
+++ /dev/null
@@ -1,128 +0,0 @@
-.. This work is licensed under a Creative Commons Attribution 4.0 International
-.. License.
-.. http://creativecommons.org/licenses/by/4.0
-.. (c) OPNFV, National Center of Scientific Research "Demokritos" and others.
-
-==========================
-Virtual Traffic Classifier
-==========================
-
-Abstract
-========
-
-.. _TNOVA: http://www.t-nova.eu/
-.. _TNOVAresults: http://www.t-nova.eu/results/
-.. _Yardstick: https://wiki.opnfv.org/yardstick
-
-This chapter provides an overview of the virtual Traffic Classifier, a
-contribution to OPNFV Yardstick_ from the EU Project TNOVA_.
-Additional documentation is available in TNOVAresults_.
-
-Overview
-========
-
-The virtual Traffic Classifier (:term:`VTC`) :term:`VNF`, comprises of a
-Virtual Network Function Component (:term:`VNFC`). The :term:`VNFC` contains
-both the Traffic Inspection module, and the Traffic forwarding module, needed
-to run the :term:`VNF`. The exploitation of Deep Packet Inspection
-(:term:`DPI`) methods for traffic classification is built around two basic
-assumptions:
-
-* third parties unaffiliated with either source or recipient are able to
-inspect each IP packet’s payload
-
-* the classifier knows the relevant syntax of each application’s packet
-payloads (protocol signatures, data patterns, etc.).
-
-The proposed :term:`DPI` based approach will only use an indicative, small
-number of the initial packets from each flow in order to identify the content
-and not inspect each packet.
-
-In this respect it follows the Packet Based per Flow State (term:`PBFS`). This
-method uses a table to track each session based on the 5-tuples (src address,
-dest address, src port,dest port, transport protocol) that is maintained for
-each flow.
-
-Concepts
-========
-
-* *Traffic Inspection*: The process of packet analysis and application
-identification of network traffic that passes through the :term:`VTC`.
-
-* *Traffic Forwarding*: The process of packet forwarding from an incoming
-network interface to a pre-defined outgoing network interface.
-
-* *Traffic Rule Application*: The process of packet tagging, based on a
-predefined set of rules. Packet tagging may include e.g. Type of Service
-(:term:`ToS`) field modification.
-
-Architecture
-============
-
-The Traffic Inspection module is the most computationally intensive component
-of the :term:`VNF`. It implements filtering and packet matching algorithms in
-order to support the enhanced traffic forwarding capability of the :term:`VNF`.
-The component supports a flow table (exploiting hashing algorithms for fast
-indexing of flows) and an inspection engine for traffic classification.
-
-The implementation used for these experiments exploits the nDPI library.
-The packet capturing mechanism is implemented using libpcap. When the
-:term:`DPI` engine identifies a new flow, the flow register is updated with the
-appropriate information and transmitted across the Traffic Forwarding module,
-which then applies any required policy updates.
-
-The Traffic Forwarding moudle is responsible for routing and packet forwarding.
-It accepts incoming network traffic, consults the flow table for classification
-information for each incoming flow and then applies pre-defined policies
-marking e.g. :term:`ToS`/Differentiated Services Code Point (:term:`DSCP`)
-multimedia traffic for Quality of Service (:term:`QoS`) enablement on the
-forwarded traffic.
-It is assumed that the traffic is forwarded using the default policy until it
-is identified and new policies are enforced.
-
-The expected response delay is considered to be negligible, as only a small
-number of packets are required to identify each flow.
-
-Graphical Overview
-==================
-
-.. code-block:: console
-
- +----------------------------+
- | |
- | Virtual Traffic Classifier |
- | |
- | Analysing/Forwarding |
- | ------------> |
- | ethA ethB |
- | |
- +----------------------------+
- | ^
- | |
- v |
- +----------------------------+
- | |
- | Virtual Switch |
- | |
- +----------------------------+
-
-Install
-=======
-
-run the vTC/build.sh with root privileges
-
-Run
-===
-
-::
-
- sudo ./pfbridge -a eth1 -b eth2
-
-
-.. note:: Virtual Traffic Classifier is not support in OPNFV Danube release.
-
-
-Development Environment
-=======================
-
-Ubuntu 14.04 Ubuntu 16.04
diff --git a/docs/testing/user/userguide/09-yardstick_user_interface.rst b/docs/testing/user/userguide/09-yardstick_user_interface.rst
new file mode 100644
index 000000000..9058dd46d
--- /dev/null
+++ b/docs/testing/user/userguide/09-yardstick_user_interface.rst
@@ -0,0 +1,29 @@
+Yardstick User Interface
+========================
+
+This interface provides a user to view the test result
+in table format and also values pinned on to a graph.
+
+
+Command
+-------
+::
+
+ yardstick report generate <task-ID> <testcase-filename>
+
+
+Description
+-----------
+
+1. When the command is triggered using the task-id and the testcase
+name provided the respective values are retrieved from the
+database (influxdb in this particular case).
+
+2. The values are then formatted and then provided to the html
+template framed with complete html body using Django Framework.
+
+3. Then the whole template is written into a html file.
+
+The graph is framed with Timestamp on x-axis and output values
+(differ from testcase to testcase) on y-axis with the help of
+"Highcharts".
diff --git a/docs/testing/user/userguide/10-apexlake_installation.rst b/docs/testing/user/userguide/10-apexlake_installation.rst
deleted file mode 100644
index 0d8ef143f..000000000
--- a/docs/testing/user/userguide/10-apexlake_installation.rst
+++ /dev/null
@@ -1,302 +0,0 @@
-.. This work is licensed under a Creative Commons Attribution 4.0 International
-.. License.
-.. http://creativecommons.org/licenses/by/4.0
-.. (c) OPNFV, Intel Corporation and others.
-
-
-.. _DPDK: http://dpdk.org/doc/nics
-.. _DPDK-pktgen: https://github.com/Pktgen/Pktgen-DPDK/
-.. _SRIOV: https://wiki.openstack.org/wiki/SR-IOV-Passthrough-For-Networking
-.. _PORTSEC: https://wiki.openstack.org/wiki/Neutron/ML2PortSecurityExtensionDriver
-.. _here: https://wiki.opnfv.org/vtc
-
-
-============================
-Apexlake Installation Guide
-============================
-
-Abstract
---------
-
-ApexLake is a framework that provides automatic execution of experiments and
-related data collection to enable a user validate infrastructure from the
-perspective of a Virtual Network Function (:term:`VNF`).
-
-In the context of Yardstick, a virtual Traffic Classifier (:term:`VTC`) network
-function is utilized.
-
-
-Framework Hardware Dependencies
-===============================
-
-In order to run the framework there are some hardware related dependencies for
-ApexLake.
-
-The framework needs to be installed on the same physical node where DPDK-pktgen_
-is installed.
-
-The installation requires the physical node hosting the packet generator must
-have 2 NICs which are DPDK_ compatible.
-
-The 2 NICs will be connected to the switch where the OpenStack VM
-network is managed.
-
-The switch used must support multicast traffic and :term:`IGMP` snooping.
-Further details about the configuration are provided at the following here_.
-
-The corresponding ports to which the cables are connected need to be configured
-as VLAN trunks using two of the VLAN IDs available for Neutron.
-Note the VLAN IDs used as they will be required in later configuration steps.
-
-
-Framework Software Dependencies
-===============================
-Before starting the framework, a number of dependencies must first be installed.
-The following describes the set of instructions to be executed via the Linux
-shell in order to install and configure the required dependencies.
-
-1. Install Dependencies.
-
-To support the framework dependencies the following packages must be installed.
-The example provided is based on Ubuntu and needs to be executed in root mode.
-
-::
-
- apt-get install python-dev
- apt-get install python-pip
- apt-get install python-mock
- apt-get install tcpreplay
- apt-get install libpcap-dev
-
-2. Source OpenStack openrc file.
-
-::
-
- source openrc
-
-3. Configure Openstack Neutron
-
-In order to support traffic generation and management by the virtual
-Traffic Classifier, the configuration of the port security driver
-extension is required for Neutron.
-
-For further details please follow the following link: PORTSEC_
-This step can be skipped in case the target OpenStack is Juno or Kilo release,
-but it is required to support Liberty.
-It is therefore required to indicate the release version in the configuration
-file located in ./yardstick/vTC/apexlake/apexlake.conf
-
-
-4. Create Two Networks based on VLANs in Neutron.
-
-To enable network communications between the packet generator and the compute
-node, two networks must be created via Neutron and mapped to the VLAN IDs
-that were previously used in the configuration of the physical switch.
-The following shows the typical set of commands required to configure Neutron
-correctly.
-The physical switches need to be configured accordingly.
-
-::
-
- VLAN_1=2032
- VLAN_2=2033
- PHYSNET=physnet2
- neutron net-create apexlake_inbound_network \
- --provider:network_type vlan \
- --provider:segmentation_id $VLAN_1 \
- --provider:physical_network $PHYSNET
-
- neutron subnet-create apexlake_inbound_network \
- 192.168.0.0/24 --name apexlake_inbound_subnet
-
- neutron net-create apexlake_outbound_network \
- --provider:network_type vlan \
- --provider:segmentation_id $VLAN_2 \
- --provider:physical_network $PHYSNET
-
- neutron subnet-create apexlake_outbound_network 192.168.1.0/24 \
- --name apexlake_outbound_subnet
-
-
-5. Download Ubuntu Cloud Image and load it on Glance
-
-The virtual Traffic Classifier is supported on top of Ubuntu 14.04 cloud image.
-The image can be downloaded on the local machine and loaded on Glance
-using the following commands:
-
-::
-
- wget cloud-images.ubuntu.com/trusty/current/trusty-server-cloudimg-amd64-disk1.img
- glance image-create \
- --name ubuntu1404 \
- --is-public true \
- --disk-format qcow \
- --container-format bare \
- --file trusty-server-cloudimg-amd64-disk1.img
-
-
-
-6. Configure the Test Cases
-
-The VLAN tags must also be included in the test case Yardstick yaml file
-as parameters for the following test cases:
-
- * :doc:`opnfv_yardstick_tc006`
-
- * :doc:`opnfv_yardstick_tc007`
-
- * :doc:`opnfv_yardstick_tc020`
-
- * :doc:`opnfv_yardstick_tc021`
-
-
-Install and Configure DPDK Pktgen
-+++++++++++++++++++++++++++++++++
-
-Execution of the framework is based on DPDK Pktgen.
-If DPDK Pktgen has not installed, it is necessary to download, install, compile
-and configure it.
-The user can create a directory and download the dpdk packet generator source
-code:
-
-::
-
- cd experimental_framework/libraries
- mkdir dpdk_pktgen
- git clone https://github.com/pktgen/Pktgen-DPDK.git
-
-For instructions on the installation and configuration of DPDK and DPDK Pktgen
-please follow the official DPDK Pktgen README file.
-Once the installation is completed, it is necessary to load the DPDK kernel
-driver, as follow:
-
-::
-
- insmod uio
- insmod DPDK_DIR/x86_64-native-linuxapp-gcc/kmod/igb_uio.ko
-
-It is necessary to set the configuration file to support the desired Pktgen
-configuration.
-A description of the required configuration parameters and supporting examples
-is provided in the following:
-
-::
-
- [PacketGen]
- packet_generator = dpdk_pktgen
-
- # This is the directory where the packet generator is installed
- # (if the user previously installed dpdk-pktgen,
- # it is required to provide the director where it is installed).
- pktgen_directory = /home/user/software/dpdk_pktgen/dpdk/examples/pktgen/
-
- # This is the directory where DPDK is installed
- dpdk_directory = /home/user/apexlake/experimental_framework/libraries/Pktgen-DPDK/dpdk/
-
- # Name of the dpdk-pktgen program that starts the packet generator
- program_name = app/app/x86_64-native-linuxapp-gcc/pktgen
-
- # DPDK coremask (see DPDK-Pktgen readme)
- coremask = 1f
-
- # DPDK memory channels (see DPDK-Pktgen readme)
- memory_channels = 3
-
- # Name of the interface of the pktgen to be used to send traffic (vlan_sender)
- name_if_1 = p1p1
-
- # Name of the interface of the pktgen to be used to receive traffic (vlan_receiver)
- name_if_2 = p1p2
-
- # PCI bus address correspondent to if_1
- bus_slot_nic_1 = 01:00.0
-
- # PCI bus address correspondent to if_2
- bus_slot_nic_2 = 01:00.1
-
-
-To find the parameters related to names of the NICs and the addresses of the PCI buses
-the user may find it useful to run the :term:`DPDK` tool nic_bind as follows:
-
-::
-
- DPDK_DIR/tools/dpdk_nic_bind.py --status
-
-Lists the NICs available on the system, and shows the available drivers and bus addresses for each interface.
-Please make sure to select NICs which are :term:`DPDK` compatible.
-
-Installation and Configuration of smcroute
-++++++++++++++++++++++++++++++++++++++++++
-
-The user is required to install smcroute which is used by the framework to
-support multicast communications.
-
-The following is the list of commands required to download and install smroute.
-
-::
-
- cd ~
- git clone https://github.com/troglobit/smcroute.git
- cd smcroute
- git reset --hard c3f5c56
- sed -i 's/aclocal-1.11/aclocal/g' ./autogen.sh
- sed -i 's/automake-1.11/automake/g' ./autogen.sh
- ./autogen.sh
- ./configure
- make
- sudo make install
- cd ..
-
-It is required to do the reset to the specified commit ID.
-It is also requires the creation a configuration file using the following
-command:
-
-::
-
- SMCROUTE_NIC=(name of the nic)
-
-where name of the nic is the name used previously for the variable "name_if_2".
-For example:
-
-::
-
- SMCROUTE_NIC=p1p2
-
-Then create the smcroute configuration file /etc/smcroute.conf
-
-::
-
- echo mgroup from $SMCROUTE_NIC group 224.192.16.1 > /etc/smcroute.conf
-
-
-At the end of this procedure it will be necessary to perform the following
-actions to add the user to the sudoers:
-
-::
-
- adduser USERNAME sudo
- echo "user ALL=(ALL) NOPASSWD: ALL" >> /etc/sudoers
-
-
-Experiment using SR-IOV Configuration on the Compute Node
-+++++++++++++++++++++++++++++++++++++++++++++++++++++++++
-
-To enable :term:`SR-IOV` interfaces on the physical NIC of the compute node, a
-compatible NIC is required.
-NIC configuration depends on model and vendor. After proper configuration to
-support :term:`SR-IOV`, a proper configuration of OpenStack is required.
-For further information, please refer to the SRIOV_ configuration guide
-
-Finalize installation the framework on the system
-=================================================
-
-The installation of the framework on the system requires the setup of the project.
-After entering into the apexlake directory, it is sufficient to run the following
-command.
-
-::
-
- python setup.py install
-
-Since some elements are copied into the /tmp directory (see configuration file)
-it could be necessary to repeat this step after a reboot of the host.
diff --git a/docs/testing/user/userguide/10-vtc-overview.rst b/docs/testing/user/userguide/10-vtc-overview.rst
new file mode 100644
index 000000000..8ed17873d
--- /dev/null
+++ b/docs/testing/user/userguide/10-vtc-overview.rst
@@ -0,0 +1,128 @@
+.. This work is licensed under a Creative Commons Attribution 4.0 International
+.. License.
+.. http://creativecommons.org/licenses/by/4.0
+.. (c) OPNFV, National Center of Scientific Research "Demokritos" and others.
+
+==========================
+Virtual Traffic Classifier
+==========================
+
+Abstract
+========
+
+.. _TNOVA: http://www.t-nova.eu/
+.. _TNOVAresults: http://www.t-nova.eu/results/
+.. _Yardstick: https://wiki.opnfv.org/yardstick
+
+This chapter provides an overview of the virtual Traffic Classifier, a
+contribution to OPNFV Yardstick_ from the EU Project TNOVA_.
+Additional documentation is available in TNOVAresults_.
+
+Overview
+========
+
+The virtual Traffic Classifier (:term:`VTC`) :term:`VNF`, comprises of a
+Virtual Network Function Component (:term:`VNFC`). The :term:`VNFC` contains
+both the Traffic Inspection module, and the Traffic forwarding module, needed
+to run the :term:`VNF`. The exploitation of Deep Packet Inspection
+(:term:`DPI`) methods for traffic classification is built around two basic
+assumptions:
+
+* third parties unaffiliated with either source or recipient are able to
+inspect each IP packet’s payload
+
+* the classifier knows the relevant syntax of each application’s packet
+payloads (protocol signatures, data patterns, etc.).
+
+The proposed :term:`DPI` based approach will only use an indicative, small
+number of the initial packets from each flow in order to identify the content
+and not inspect each packet.
+
+In this respect it follows the Packet Based per Flow State (term:`PBFS`). This
+method uses a table to track each session based on the 5-tuples (src address,
+dest address, src port,dest port, transport protocol) that is maintained for
+each flow.
+
+Concepts
+========
+
+* *Traffic Inspection*: The process of packet analysis and application
+identification of network traffic that passes through the :term:`VTC`.
+
+* *Traffic Forwarding*: The process of packet forwarding from an incoming
+network interface to a pre-defined outgoing network interface.
+
+* *Traffic Rule Application*: The process of packet tagging, based on a
+predefined set of rules. Packet tagging may include e.g. Type of Service
+(:term:`ToS`) field modification.
+
+Architecture
+============
+
+The Traffic Inspection module is the most computationally intensive component
+of the :term:`VNF`. It implements filtering and packet matching algorithms in
+order to support the enhanced traffic forwarding capability of the :term:`VNF`.
+The component supports a flow table (exploiting hashing algorithms for fast
+indexing of flows) and an inspection engine for traffic classification.
+
+The implementation used for these experiments exploits the nDPI library.
+The packet capturing mechanism is implemented using libpcap. When the
+:term:`DPI` engine identifies a new flow, the flow register is updated with the
+appropriate information and transmitted across the Traffic Forwarding module,
+which then applies any required policy updates.
+
+The Traffic Forwarding moudle is responsible for routing and packet forwarding.
+It accepts incoming network traffic, consults the flow table for classification
+information for each incoming flow and then applies pre-defined policies
+marking e.g. :term:`ToS`/Differentiated Services Code Point (:term:`DSCP`)
+multimedia traffic for Quality of Service (:term:`QoS`) enablement on the
+forwarded traffic.
+It is assumed that the traffic is forwarded using the default policy until it
+is identified and new policies are enforced.
+
+The expected response delay is considered to be negligible, as only a small
+number of packets are required to identify each flow.
+
+Graphical Overview
+==================
+
+.. code-block:: console
+
+ +----------------------------+
+ | |
+ | Virtual Traffic Classifier |
+ | |
+ | Analysing/Forwarding |
+ | ------------> |
+ | ethA ethB |
+ | |
+ +----------------------------+
+ | ^
+ | |
+ v |
+ +----------------------------+
+ | |
+ | Virtual Switch |
+ | |
+ +----------------------------+
+
+Install
+=======
+
+run the vTC/build.sh with root privileges
+
+Run
+===
+
+::
+
+ sudo ./pfbridge -a eth1 -b eth2
+
+
+.. note:: Virtual Traffic Classifier is not support in OPNFV Danube release.
+
+
+Development Environment
+=======================
+
+Ubuntu 14.04 Ubuntu 16.04
diff --git a/docs/testing/user/userguide/11-apexlake_api.rst b/docs/testing/user/userguide/11-apexlake_api.rst
deleted file mode 100644
index 35a1dbe3e..000000000
--- a/docs/testing/user/userguide/11-apexlake_api.rst
+++ /dev/null
@@ -1,89 +0,0 @@
-.. This work is licensed under a Creative Commons Attribution 4.0 International
-.. License.
-.. http://creativecommons.org/licenses/by/4.0
-.. (c) OPNFV, Intel Corporation and others.
-
-
-=================================
-Apexlake API Interface Definition
-=================================
-
-Abstract
---------
-
-The API interface provided by the framework to enable the execution of test
-cases is defined as follows.
-
-
-init
-----
-
-**static init()**
-
- Initializes the Framework
-
- **Returns** None
-
-
-execute_framework
------------------
-
-**static execute_framework** (test_cases,
-
- iterations,
-
- heat_template,
-
- heat_template_parameters,
-
- deployment_configuration,
-
- openstack_credentials)
-
- Executes the framework according the specified inputs
-
- **Parameters**
-
- - **test_cases**
-
- Test cases to be run with the workload (dict() of dict())
-
- Example:
- test_case = dict()
-
- test_case[’name’] = ‘module.Class’
-
- test_case[’params’] = dict()
-
- test_case[’params’][’throughput’] = ‘1’
-
- test_case[’params’][’vlan_sender’] = ‘1000’
-
- test_case[’params’][’vlan_receiver’] = ‘1001’
-
- test_cases = [test_case]
-
- - **iterations**
- Number of test cycles to be executed (int)
-
- - **heat_template**
- (string) File name of the heat template corresponding to the workload to be deployed.
- It contains the parameters to be evaluated in the form of #parameter_name.
- (See heat_templates/vTC.yaml as example).
-
- - **heat_template_parameters**
- (dict) Parameters to be provided as input to the
- heat template. See http://docs.openstack.org/developer/heat/ template_guide/hot_guide.html
- section “Template input parameters” for further info.
-
- - **deployment_configuration**
- ( dict[string] = list(strings) ) ) Dictionary of parameters
- representing the deployment configuration of the workload.
-
- The key is a string corresponding to the name of the parameter,
- the value is a list of strings representing the value to be
- assumed by a specific param. The parameters are user defined:
- they have to correspond to the place holders (#parameter_name)
- specified in the heat template.
-
- **Returns** dict() containing results
diff --git a/docs/testing/user/userguide/11-apexlake_installation.rst b/docs/testing/user/userguide/11-apexlake_installation.rst
new file mode 100644
index 000000000..0d8ef143f
--- /dev/null
+++ b/docs/testing/user/userguide/11-apexlake_installation.rst
@@ -0,0 +1,302 @@
+.. This work is licensed under a Creative Commons Attribution 4.0 International
+.. License.
+.. http://creativecommons.org/licenses/by/4.0
+.. (c) OPNFV, Intel Corporation and others.
+
+
+.. _DPDK: http://dpdk.org/doc/nics
+.. _DPDK-pktgen: https://github.com/Pktgen/Pktgen-DPDK/
+.. _SRIOV: https://wiki.openstack.org/wiki/SR-IOV-Passthrough-For-Networking
+.. _PORTSEC: https://wiki.openstack.org/wiki/Neutron/ML2PortSecurityExtensionDriver
+.. _here: https://wiki.opnfv.org/vtc
+
+
+============================
+Apexlake Installation Guide
+============================
+
+Abstract
+--------
+
+ApexLake is a framework that provides automatic execution of experiments and
+related data collection to enable a user validate infrastructure from the
+perspective of a Virtual Network Function (:term:`VNF`).
+
+In the context of Yardstick, a virtual Traffic Classifier (:term:`VTC`) network
+function is utilized.
+
+
+Framework Hardware Dependencies
+===============================
+
+In order to run the framework there are some hardware related dependencies for
+ApexLake.
+
+The framework needs to be installed on the same physical node where DPDK-pktgen_
+is installed.
+
+The installation requires the physical node hosting the packet generator must
+have 2 NICs which are DPDK_ compatible.
+
+The 2 NICs will be connected to the switch where the OpenStack VM
+network is managed.
+
+The switch used must support multicast traffic and :term:`IGMP` snooping.
+Further details about the configuration are provided at the following here_.
+
+The corresponding ports to which the cables are connected need to be configured
+as VLAN trunks using two of the VLAN IDs available for Neutron.
+Note the VLAN IDs used as they will be required in later configuration steps.
+
+
+Framework Software Dependencies
+===============================
+Before starting the framework, a number of dependencies must first be installed.
+The following describes the set of instructions to be executed via the Linux
+shell in order to install and configure the required dependencies.
+
+1. Install Dependencies.
+
+To support the framework dependencies the following packages must be installed.
+The example provided is based on Ubuntu and needs to be executed in root mode.
+
+::
+
+ apt-get install python-dev
+ apt-get install python-pip
+ apt-get install python-mock
+ apt-get install tcpreplay
+ apt-get install libpcap-dev
+
+2. Source OpenStack openrc file.
+
+::
+
+ source openrc
+
+3. Configure Openstack Neutron
+
+In order to support traffic generation and management by the virtual
+Traffic Classifier, the configuration of the port security driver
+extension is required for Neutron.
+
+For further details please follow the following link: PORTSEC_
+This step can be skipped in case the target OpenStack is Juno or Kilo release,
+but it is required to support Liberty.
+It is therefore required to indicate the release version in the configuration
+file located in ./yardstick/vTC/apexlake/apexlake.conf
+
+
+4. Create Two Networks based on VLANs in Neutron.
+
+To enable network communications between the packet generator and the compute
+node, two networks must be created via Neutron and mapped to the VLAN IDs
+that were previously used in the configuration of the physical switch.
+The following shows the typical set of commands required to configure Neutron
+correctly.
+The physical switches need to be configured accordingly.
+
+::
+
+ VLAN_1=2032
+ VLAN_2=2033
+ PHYSNET=physnet2
+ neutron net-create apexlake_inbound_network \
+ --provider:network_type vlan \
+ --provider:segmentation_id $VLAN_1 \
+ --provider:physical_network $PHYSNET
+
+ neutron subnet-create apexlake_inbound_network \
+ 192.168.0.0/24 --name apexlake_inbound_subnet
+
+ neutron net-create apexlake_outbound_network \
+ --provider:network_type vlan \
+ --provider:segmentation_id $VLAN_2 \
+ --provider:physical_network $PHYSNET
+
+ neutron subnet-create apexlake_outbound_network 192.168.1.0/24 \
+ --name apexlake_outbound_subnet
+
+
+5. Download Ubuntu Cloud Image and load it on Glance
+
+The virtual Traffic Classifier is supported on top of Ubuntu 14.04 cloud image.
+The image can be downloaded on the local machine and loaded on Glance
+using the following commands:
+
+::
+
+ wget cloud-images.ubuntu.com/trusty/current/trusty-server-cloudimg-amd64-disk1.img
+ glance image-create \
+ --name ubuntu1404 \
+ --is-public true \
+ --disk-format qcow \
+ --container-format bare \
+ --file trusty-server-cloudimg-amd64-disk1.img
+
+
+
+6. Configure the Test Cases
+
+The VLAN tags must also be included in the test case Yardstick yaml file
+as parameters for the following test cases:
+
+ * :doc:`opnfv_yardstick_tc006`
+
+ * :doc:`opnfv_yardstick_tc007`
+
+ * :doc:`opnfv_yardstick_tc020`
+
+ * :doc:`opnfv_yardstick_tc021`
+
+
+Install and Configure DPDK Pktgen
++++++++++++++++++++++++++++++++++
+
+Execution of the framework is based on DPDK Pktgen.
+If DPDK Pktgen has not installed, it is necessary to download, install, compile
+and configure it.
+The user can create a directory and download the dpdk packet generator source
+code:
+
+::
+
+ cd experimental_framework/libraries
+ mkdir dpdk_pktgen
+ git clone https://github.com/pktgen/Pktgen-DPDK.git
+
+For instructions on the installation and configuration of DPDK and DPDK Pktgen
+please follow the official DPDK Pktgen README file.
+Once the installation is completed, it is necessary to load the DPDK kernel
+driver, as follow:
+
+::
+
+ insmod uio
+ insmod DPDK_DIR/x86_64-native-linuxapp-gcc/kmod/igb_uio.ko
+
+It is necessary to set the configuration file to support the desired Pktgen
+configuration.
+A description of the required configuration parameters and supporting examples
+is provided in the following:
+
+::
+
+ [PacketGen]
+ packet_generator = dpdk_pktgen
+
+ # This is the directory where the packet generator is installed
+ # (if the user previously installed dpdk-pktgen,
+ # it is required to provide the director where it is installed).
+ pktgen_directory = /home/user/software/dpdk_pktgen/dpdk/examples/pktgen/
+
+ # This is the directory where DPDK is installed
+ dpdk_directory = /home/user/apexlake/experimental_framework/libraries/Pktgen-DPDK/dpdk/
+
+ # Name of the dpdk-pktgen program that starts the packet generator
+ program_name = app/app/x86_64-native-linuxapp-gcc/pktgen
+
+ # DPDK coremask (see DPDK-Pktgen readme)
+ coremask = 1f
+
+ # DPDK memory channels (see DPDK-Pktgen readme)
+ memory_channels = 3
+
+ # Name of the interface of the pktgen to be used to send traffic (vlan_sender)
+ name_if_1 = p1p1
+
+ # Name of the interface of the pktgen to be used to receive traffic (vlan_receiver)
+ name_if_2 = p1p2
+
+ # PCI bus address correspondent to if_1
+ bus_slot_nic_1 = 01:00.0
+
+ # PCI bus address correspondent to if_2
+ bus_slot_nic_2 = 01:00.1
+
+
+To find the parameters related to names of the NICs and the addresses of the PCI buses
+the user may find it useful to run the :term:`DPDK` tool nic_bind as follows:
+
+::
+
+ DPDK_DIR/tools/dpdk_nic_bind.py --status
+
+Lists the NICs available on the system, and shows the available drivers and bus addresses for each interface.
+Please make sure to select NICs which are :term:`DPDK` compatible.
+
+Installation and Configuration of smcroute
+++++++++++++++++++++++++++++++++++++++++++
+
+The user is required to install smcroute which is used by the framework to
+support multicast communications.
+
+The following is the list of commands required to download and install smroute.
+
+::
+
+ cd ~
+ git clone https://github.com/troglobit/smcroute.git
+ cd smcroute
+ git reset --hard c3f5c56
+ sed -i 's/aclocal-1.11/aclocal/g' ./autogen.sh
+ sed -i 's/automake-1.11/automake/g' ./autogen.sh
+ ./autogen.sh
+ ./configure
+ make
+ sudo make install
+ cd ..
+
+It is required to do the reset to the specified commit ID.
+It is also requires the creation a configuration file using the following
+command:
+
+::
+
+ SMCROUTE_NIC=(name of the nic)
+
+where name of the nic is the name used previously for the variable "name_if_2".
+For example:
+
+::
+
+ SMCROUTE_NIC=p1p2
+
+Then create the smcroute configuration file /etc/smcroute.conf
+
+::
+
+ echo mgroup from $SMCROUTE_NIC group 224.192.16.1 > /etc/smcroute.conf
+
+
+At the end of this procedure it will be necessary to perform the following
+actions to add the user to the sudoers:
+
+::
+
+ adduser USERNAME sudo
+ echo "user ALL=(ALL) NOPASSWD: ALL" >> /etc/sudoers
+
+
+Experiment using SR-IOV Configuration on the Compute Node
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+
+To enable :term:`SR-IOV` interfaces on the physical NIC of the compute node, a
+compatible NIC is required.
+NIC configuration depends on model and vendor. After proper configuration to
+support :term:`SR-IOV`, a proper configuration of OpenStack is required.
+For further information, please refer to the SRIOV_ configuration guide
+
+Finalize installation the framework on the system
+=================================================
+
+The installation of the framework on the system requires the setup of the project.
+After entering into the apexlake directory, it is sufficient to run the following
+command.
+
+::
+
+ python setup.py install
+
+Since some elements are copied into the /tmp directory (see configuration file)
+it could be necessary to repeat this step after a reboot of the host.
diff --git a/docs/testing/user/userguide/12-apexlake_api.rst b/docs/testing/user/userguide/12-apexlake_api.rst
new file mode 100644
index 000000000..35a1dbe3e
--- /dev/null
+++ b/docs/testing/user/userguide/12-apexlake_api.rst
@@ -0,0 +1,89 @@
+.. This work is licensed under a Creative Commons Attribution 4.0 International
+.. License.
+.. http://creativecommons.org/licenses/by/4.0
+.. (c) OPNFV, Intel Corporation and others.
+
+
+=================================
+Apexlake API Interface Definition
+=================================
+
+Abstract
+--------
+
+The API interface provided by the framework to enable the execution of test
+cases is defined as follows.
+
+
+init
+----
+
+**static init()**
+
+ Initializes the Framework
+
+ **Returns** None
+
+
+execute_framework
+-----------------
+
+**static execute_framework** (test_cases,
+
+ iterations,
+
+ heat_template,
+
+ heat_template_parameters,
+
+ deployment_configuration,
+
+ openstack_credentials)
+
+ Executes the framework according the specified inputs
+
+ **Parameters**
+
+ - **test_cases**
+
+ Test cases to be run with the workload (dict() of dict())
+
+ Example:
+ test_case = dict()
+
+ test_case[’name’] = ‘module.Class’
+
+ test_case[’params’] = dict()
+
+ test_case[’params’][’throughput’] = ‘1’
+
+ test_case[’params’][’vlan_sender’] = ‘1000’
+
+ test_case[’params’][’vlan_receiver’] = ‘1001’
+
+ test_cases = [test_case]
+
+ - **iterations**
+ Number of test cycles to be executed (int)
+
+ - **heat_template**
+ (string) File name of the heat template corresponding to the workload to be deployed.
+ It contains the parameters to be evaluated in the form of #parameter_name.
+ (See heat_templates/vTC.yaml as example).
+
+ - **heat_template_parameters**
+ (dict) Parameters to be provided as input to the
+ heat template. See http://docs.openstack.org/developer/heat/ template_guide/hot_guide.html
+ section “Template input parameters” for further info.
+
+ - **deployment_configuration**
+ ( dict[string] = list(strings) ) ) Dictionary of parameters
+ representing the deployment configuration of the workload.
+
+ The key is a string corresponding to the name of the parameter,
+ the value is a list of strings representing the value to be
+ assumed by a specific param. The parameters are user defined:
+ they have to correspond to the place holders (#parameter_name)
+ specified in the heat template.
+
+ **Returns** dict() containing results
diff --git a/docs/testing/user/userguide/12-nsb-overview.rst b/docs/testing/user/userguide/12-nsb-overview.rst
deleted file mode 100644
index faac61f08..000000000
--- a/docs/testing/user/userguide/12-nsb-overview.rst
+++ /dev/null
@@ -1,194 +0,0 @@
-.. This work is licensed under a Creative Commons Attribution 4.0 International
-.. License.
-.. http://creativecommons.org/licenses/by/4.0
-.. (c) OPNFV, 2016-2017 Intel Corporation.
-
-=====================================
-Network Services Benchmarking (NSB)
-=====================================
-
-Abstract
-========
-
-.. _Yardstick: https://wiki.opnfv.org/yardstick
-
-This chapter provides an overview of the NSB, a contribution to OPNFV
-Yardstick_ from Intel.
-
-Overview
-========
-
-GOAL: Extend Yardstick to perform real world VNFs and NFVi Characterization and
-benchmarking with repeatable and deterministic methods.
-
-The Network Service Benchmarking (NSB) extends the yardstick framework to do
-VNF characterization and benchmarking in three different execution
-environments - bare metal i.e. native Linux environment, standalone virtual
-environment and managed virtualized environment (e.g. Open stack etc.).
-It also brings in the capability to interact with external traffic generators
-both hardware & software based for triggering and validating the traffic
-according to user defined profiles.
-
-NSB extension includes:
-
- - Generic data models of Network Services, based on ETSI spec (ETSI GS NFV-TST 001)
- .. _ETSI GS NFV-TST 001: http://www.etsi.org/deliver/etsi_gs/NFV-TST/001_099/001/01.01.01_60/gs_nfv-tst001v010101p.pdf
-
- - New Standalone context for VNF testing like SRIOV, OVS, OVS-DPDK etc
-
- - Generic VNF configuration models and metrics implemented with Python
- classes
-
- - Traffic generator features and traffic profiles
-
- - L1-L3 state-less traffic profiles
-
- - L4-L7 state-full traffic profiles
-
- - Tunneling protocol / network overlay support
-
- - Test case samples
-
- - Ping
-
- - Trex
-
- - vPE,vCGNAT, vFirewall etc - ipv4 throughput, latency etc
-
- - Traffic generators like Trex, ab/nginx, ixia, iperf etc
-
- - KPIs for a given use case:
-
- - System agent support for collecting NFVi KPI. This includes:
-
- - CPU statistic
-
- - Memory BW
-
- - OVS-DPDK Stats
-
- - Network KPIs, e.g., inpackets, outpackets, thoughput, latency etc
-
- - VNF KPIs, e.g., packet_in, packet_drop, packet_fwd etc
-
-Architecture
-============
-The Network Service (NS) defines a set of Virtual Network Functions (VNF)
-connected together using NFV infrastructure.
-
-The Yardstick NSB extension can support multiple VNFs created by different
-vendors including traffic generators. Every VNF being tested has its
-own data model. The Network service defines a VNF modelling on base of performed
-network functionality. The part of the data model is a set of the configuration
-parameters, number of connection points used and flavor including core and
-memory amount.
-
-The ETSI defines a Network Service as a set of configurable VNFs working in
-some NFV Infrastructure connecting each other using Virtual Links available
-through Connection Points. The ETSI MANO specification defines a set of
-management entities called Network Service Descriptors (NSD) and
-VNF Descriptors (VNFD) that define real Network Service. The picture below
-makes an example how the real Network Operator use-case can map into ETSI
-Network service definition
-
-Network Service framework performs the necessary test steps. It may involve
-
- - Interacting with traffic generator and providing the inputs on traffic
- type / packet structure to generate the required traffic as per the
- test case. Traffic profiles will be used for this.
-
- - Executing the commands required for the test procedure and analyses the
- command output for confirming whether the command got executed correctly
- or not. E.g. As per the test case, run the traffic for the given
- time period / wait for the necessary time delay
-
- - Verify the test result.
-
- - Validate the traffic flow from SUT
-
- - Fetch the table / data from SUT and verify the value as per the test case
-
- - Upload the logs from SUT onto the Test Harness server
-
- - Read the KPI's provided by particular VNF
-
-Components of Network Service
-------------------------------
-
-* *Models for Network Service benchmarking*: The Network Service benchmarking
- requires the proper modelling approach. The NSB provides models using Python
- files and defining of NSDs and VNFDs.
-
-The benchmark control application being a part of OPNFV yardstick can call
-that python models to instantiate and configure the VNFs. Depending on
-infrastructure type (bare-metal or fully virtualized) that calls could be
-made directly or using MANO system.
-
-* *Traffic generators in NSB*: Any benchmark application requires a set of
- traffic generator and traffic profiles defining the method in which traffic
- is generated.
-
-The Network Service benchmarking model extends the Network Service
-definition with a set of Traffic Generators (TG) that are treated
-same way as other VNFs being a part of benchmarked network service.
-Same as other VNFs the traffic generator are instantiated and terminated.
-
-Every traffic generator has own configuration defined as a traffic profile and
-a set of KPIs supported. The python models for TG is extended by specific calls
-to listen and generate traffic.
-
-* *The stateless TREX traffic generator*: The main traffic generator used as
- Network Service stimulus is open source TREX tool.
-
-The TREX tool can generate any kind of stateless traffic.
-
-.. code-block:: console
-
- +--------+ +-------+ +--------+
- | | | | | |
- | Trex | ---> | VNF | ---> | Trex |
- | | | | | |
- +--------+ +-------+ +--------+
-
-Supported testcases scenarios:
-
- - Correlated UDP traffic using TREX traffic generator and replay VNF.
-
- - using different IMIX configuration like pure voice, pure video traffic etc
-
- - using different number IP flows like 1 flow, 1K, 16K, 64K, 256K, 1M flows
-
- - Using different number of rules configured like 1 rule, 1K, 10K rules
-
-For UDP correlated traffic following Key Performance Indicators are collected
-for every combination of test case parameters:
-
- - RFC2544 throughput for various loss rate defined (1% is a default)
-
-Graphical Overview
-==================
-
-NSB Testing with yardstick framework facilitate performance testing of various
-VNFs provided.
-
-.. code-block:: console
-
- +-----------+
- | | +-----------+
- | vPE | ->|TGen Port 0|
- | TestCase | | +-----------+
- | | |
- +-----------+ +------------------+ +-------+ |
- | | -- API --> | VNF | <--->
- +-----------+ | Yardstick | +-------+ |
- | Test Case | --> | NSB Testing | |
- +-----------+ | | |
- | | | |
- | +------------------+ |
- +-----------+ | +-----------+
- | Traffic | ->|TGen Port 1|
- | patterns | +-----------+
- +-----------+
-
- Figure 1: Network Service - 2 server configuration
-
diff --git a/docs/testing/user/userguide/13-nsb-overview.rst b/docs/testing/user/userguide/13-nsb-overview.rst
new file mode 100644
index 000000000..faac61f08
--- /dev/null
+++ b/docs/testing/user/userguide/13-nsb-overview.rst
@@ -0,0 +1,194 @@
+.. This work is licensed under a Creative Commons Attribution 4.0 International
+.. License.
+.. http://creativecommons.org/licenses/by/4.0
+.. (c) OPNFV, 2016-2017 Intel Corporation.
+
+=====================================
+Network Services Benchmarking (NSB)
+=====================================
+
+Abstract
+========
+
+.. _Yardstick: https://wiki.opnfv.org/yardstick
+
+This chapter provides an overview of the NSB, a contribution to OPNFV
+Yardstick_ from Intel.
+
+Overview
+========
+
+GOAL: Extend Yardstick to perform real world VNFs and NFVi Characterization and
+benchmarking with repeatable and deterministic methods.
+
+The Network Service Benchmarking (NSB) extends the yardstick framework to do
+VNF characterization and benchmarking in three different execution
+environments - bare metal i.e. native Linux environment, standalone virtual
+environment and managed virtualized environment (e.g. Open stack etc.).
+It also brings in the capability to interact with external traffic generators
+both hardware & software based for triggering and validating the traffic
+according to user defined profiles.
+
+NSB extension includes:
+
+ - Generic data models of Network Services, based on ETSI spec (ETSI GS NFV-TST 001)
+ .. _ETSI GS NFV-TST 001: http://www.etsi.org/deliver/etsi_gs/NFV-TST/001_099/001/01.01.01_60/gs_nfv-tst001v010101p.pdf
+
+ - New Standalone context for VNF testing like SRIOV, OVS, OVS-DPDK etc
+
+ - Generic VNF configuration models and metrics implemented with Python
+ classes
+
+ - Traffic generator features and traffic profiles
+
+ - L1-L3 state-less traffic profiles
+
+ - L4-L7 state-full traffic profiles
+
+ - Tunneling protocol / network overlay support
+
+ - Test case samples
+
+ - Ping
+
+ - Trex
+
+ - vPE,vCGNAT, vFirewall etc - ipv4 throughput, latency etc
+
+ - Traffic generators like Trex, ab/nginx, ixia, iperf etc
+
+ - KPIs for a given use case:
+
+ - System agent support for collecting NFVi KPI. This includes:
+
+ - CPU statistic
+
+ - Memory BW
+
+ - OVS-DPDK Stats
+
+ - Network KPIs, e.g., inpackets, outpackets, thoughput, latency etc
+
+ - VNF KPIs, e.g., packet_in, packet_drop, packet_fwd etc
+
+Architecture
+============
+The Network Service (NS) defines a set of Virtual Network Functions (VNF)
+connected together using NFV infrastructure.
+
+The Yardstick NSB extension can support multiple VNFs created by different
+vendors including traffic generators. Every VNF being tested has its
+own data model. The Network service defines a VNF modelling on base of performed
+network functionality. The part of the data model is a set of the configuration
+parameters, number of connection points used and flavor including core and
+memory amount.
+
+The ETSI defines a Network Service as a set of configurable VNFs working in
+some NFV Infrastructure connecting each other using Virtual Links available
+through Connection Points. The ETSI MANO specification defines a set of
+management entities called Network Service Descriptors (NSD) and
+VNF Descriptors (VNFD) that define real Network Service. The picture below
+makes an example how the real Network Operator use-case can map into ETSI
+Network service definition
+
+Network Service framework performs the necessary test steps. It may involve
+
+ - Interacting with traffic generator and providing the inputs on traffic
+ type / packet structure to generate the required traffic as per the
+ test case. Traffic profiles will be used for this.
+
+ - Executing the commands required for the test procedure and analyses the
+ command output for confirming whether the command got executed correctly
+ or not. E.g. As per the test case, run the traffic for the given
+ time period / wait for the necessary time delay
+
+ - Verify the test result.
+
+ - Validate the traffic flow from SUT
+
+ - Fetch the table / data from SUT and verify the value as per the test case
+
+ - Upload the logs from SUT onto the Test Harness server
+
+ - Read the KPI's provided by particular VNF
+
+Components of Network Service
+------------------------------
+
+* *Models for Network Service benchmarking*: The Network Service benchmarking
+ requires the proper modelling approach. The NSB provides models using Python
+ files and defining of NSDs and VNFDs.
+
+The benchmark control application being a part of OPNFV yardstick can call
+that python models to instantiate and configure the VNFs. Depending on
+infrastructure type (bare-metal or fully virtualized) that calls could be
+made directly or using MANO system.
+
+* *Traffic generators in NSB*: Any benchmark application requires a set of
+ traffic generator and traffic profiles defining the method in which traffic
+ is generated.
+
+The Network Service benchmarking model extends the Network Service
+definition with a set of Traffic Generators (TG) that are treated
+same way as other VNFs being a part of benchmarked network service.
+Same as other VNFs the traffic generator are instantiated and terminated.
+
+Every traffic generator has own configuration defined as a traffic profile and
+a set of KPIs supported. The python models for TG is extended by specific calls
+to listen and generate traffic.
+
+* *The stateless TREX traffic generator*: The main traffic generator used as
+ Network Service stimulus is open source TREX tool.
+
+The TREX tool can generate any kind of stateless traffic.
+
+.. code-block:: console
+
+ +--------+ +-------+ +--------+
+ | | | | | |
+ | Trex | ---> | VNF | ---> | Trex |
+ | | | | | |
+ +--------+ +-------+ +--------+
+
+Supported testcases scenarios:
+
+ - Correlated UDP traffic using TREX traffic generator and replay VNF.
+
+ - using different IMIX configuration like pure voice, pure video traffic etc
+
+ - using different number IP flows like 1 flow, 1K, 16K, 64K, 256K, 1M flows
+
+ - Using different number of rules configured like 1 rule, 1K, 10K rules
+
+For UDP correlated traffic following Key Performance Indicators are collected
+for every combination of test case parameters:
+
+ - RFC2544 throughput for various loss rate defined (1% is a default)
+
+Graphical Overview
+==================
+
+NSB Testing with yardstick framework facilitate performance testing of various
+VNFs provided.
+
+.. code-block:: console
+
+ +-----------+
+ | | +-----------+
+ | vPE | ->|TGen Port 0|
+ | TestCase | | +-----------+
+ | | |
+ +-----------+ +------------------+ +-------+ |
+ | | -- API --> | VNF | <--->
+ +-----------+ | Yardstick | +-------+ |
+ | Test Case | --> | NSB Testing | |
+ +-----------+ | | |
+ | | | |
+ | +------------------+ |
+ +-----------+ | +-----------+
+ | Traffic | ->|TGen Port 1|
+ | patterns | +-----------+
+ +-----------+
+
+ Figure 1: Network Service - 2 server configuration
+
diff --git a/docs/testing/user/userguide/13-nsb_installation.rst b/docs/testing/user/userguide/13-nsb_installation.rst
deleted file mode 100644
index 3eb17bbca..000000000
--- a/docs/testing/user/userguide/13-nsb_installation.rst
+++ /dev/null
@@ -1,238 +0,0 @@
-.. This work is licensed under a Creative Commons Attribution 4.0 International
-.. License.
-.. http://creativecommons.org/licenses/by/4.0
-.. (c) OPNFV, 2016-2017 Intel Corporation.
-
-Yardstick - NSB Testing -Installation
-=====================================
-
-Abstract
---------
-
-The Network Service Benchmarking (NSB) extends the yardstick framework to do
-VNF characterization and benchmarking in three different execution
-environments viz., bare metal i.e. native Linux environment, standalone virtual
-environment and managed virtualized environment (e.g. Open stack etc.).
-It also brings in the capability to interact with external traffic generators
-both hardware & software based for triggering and validating the traffic
-according to user defined profiles.
-
-The steps needed to run Yardstick with NSB testing are:
-
-* Install Yardstick (NSB Testing).
-* Setup pod.yaml describing Test topology
-* Create the test configuration yaml file.
-* Run the test case.
-
-
-Prerequisites
--------------
-
-Refer chapter Yardstick Instalaltion for more information on yardstick
-prerequisites
-
-Several prerequisites are needed for Yardstick(VNF testing):
-
-- Python Modules: pyzmq, pika.
-
-- flex
-
-- bison
-
-- build-essential
-
-- automake
-
-- libtool
-
-- librabbitmq-dev
-
-- rabbitmq-server
-
-- collectd
-
-- intel-cmt-cat
-
-Install Yardstick (NSB Testing)
--------------------------------
-
-Refer chapter :doc:`04-installation` for more information on installing *Yardstick*
-
-After *Yardstick* is installed, executing the "nsb_setup.sh" script to setup
-NSB testing.
-
-::
-
- ./nsb_setup.sh
-
-It will also automatically download all the packages needed for NSB Testing setup.
-
-System Topology:
------------------
-
-.. code-block:: console
-
- +----------+ +----------+
- | | | |
- | | (0)----->(0) | Ping/ |
- | TG1 | | vPE/ |
- | | | 2Trex |
- | | (1)<-----(1) | |
- +----------+ +----------+
- trafficgen_1 vnf
-
-
-OpenStack parameters and credentials
-------------------------------------
-
-Environment variables
-^^^^^^^^^^^^^^^^^^^^^
-
-Before running Yardstick (NSB Testing) it is necessary to export traffic
-generator libraries.
-
-::
-
- source ~/.bash_profile
-
-Config yardstick conf
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-::
-
- cp ./etc/yardstick/yardstick.conf.sample /etc/yardstick/yardstick.conf
- vi /etc/yardstick/yardstick.conf
-
-Add trex_path and bin_path in 'nsb' section.
-
-::
-
- [DEFAULT]
- debug = True
- dispatcher = influxdb
-
- [dispatcher_influxdb]
- timeout = 5
- target = http://{YOUR_IP_HERE}:8086
- db_name = yardstick
- username = root
- password = root
-
- [nsb]
- trex_path=/opt/nsb_bin/trex/scripts
- bin_path=/opt/nsb_bin
-
-
-Config pod.yaml describing Topology
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-Before executing Yardstick test cases, make sure that pod.yaml reflects the
-topology and update all the required fields.
-
-::
-
- cp /etc/yardstick/nodes/pod.yaml.nsb.sample /etc/yardstick/nodes/pod.yaml
-
-Config pod.yaml
-::
- nodes:
- -
- name: trafficgen_1
- role: TrafficGen
- ip: 1.1.1.1
- user: root
- password: r00t
- interfaces:
- xe0: # logical name from topology.yaml and vnfd.yaml
- vpci: "0000:07:00.0"
- driver: i40e # default kernel driver
- dpdk_port_num: 0
- local_ip: "152.16.100.20"
- netmask: "255.255.255.0"
- local_mac: "00:00:00:00:00:01"
- xe1: # logical name from topology.yaml and vnfd.yaml
- vpci: "0000:07:00.1"
- driver: i40e # default kernel driver
- dpdk_port_num: 1
- local_ip: "152.16.40.20"
- netmask: "255.255.255.0"
- local_mac: "00:00.00:00:00:02"
-
- -
- name: vnf
- role: vnf
- ip: 1.1.1.2
- user: root
- password: r00t
- host: 1.1.1.2 #BM - host == ip, virtualized env - Host - compute node
- interfaces:
- xe0: # logical name from topology.yaml and vnfd.yaml
- vpci: "0000:07:00.0"
- driver: i40e # default kernel driver
- dpdk_port_num: 0
- local_ip: "152.16.100.19"
- netmask: "255.255.255.0"
- local_mac: "00:00:00:00:00:03"
-
- xe1: # logical name from topology.yaml and vnfd.yaml
- vpci: "0000:07:00.1"
- driver: i40e # default kernel driver
- dpdk_port_num: 1
- local_ip: "152.16.40.19"
- netmask: "255.255.255.0"
- local_mac: "00:00:00:00:00:04"
- routing_table:
- - network: "152.16.100.20"
- netmask: "255.255.255.0"
- gateway: "152.16.100.20"
- if: "xe0"
- - network: "152.16.40.20"
- netmask: "255.255.255.0"
- gateway: "152.16.40.20"
- if: "xe1"
- nd_route_tbl:
- - network: "0064:ff9b:0:0:0:0:9810:6414"
- netmask: "112"
- gateway: "0064:ff9b:0:0:0:0:9810:6414"
- if: "xe0"
- - network: "0064:ff9b:0:0:0:0:9810:2814"
- netmask: "112"
- gateway: "0064:ff9b:0:0:0:0:9810:2814"
- if: "xe1"
-
-Enable yardstick virtual environment
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-Before executing yardstick test cases, make sure to activate yardstick
-python virtual environment
-
-::
-
- source /opt/nsb_bin/yardstick_venv/bin/activate
-
-
-Run Yardstick - Network Service Testcases
------------------------------------------
-
-NS testing - using NSBperf CLI
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-::
-
- source /opt/nsb_setup/yardstick_venv/bin/activate
- PYTHONPATH: ". ~/.bash_profile"
- cd <yardstick_repo>/yardstick/cmd
-
- Execute command: ./NSPerf.py -h
- ./NSBperf.py --vnf <selected vnf> --test <rfc test>
- eg: ./NSBperf.py --vnf vpe --test tc_baremetal_rfc2544_ipv4_1flow_64B.yaml
-
-NS testing - using yardstick CLI
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-::
-
- source /opt/nsb_setup/yardstick_venv/bin/activate
- PYTHONPATH: ". ~/.bash_profile"
-
-Go to test case forlder type we want to execute.
- e.g. <yardstick repo>/samples/vnf_samples/nsut/<vnf>/
- run: yardstick --debug task start <test_case.yaml>
diff --git a/docs/testing/user/userguide/14-list-of-tcs.rst b/docs/testing/user/userguide/14-list-of-tcs.rst
deleted file mode 100644
index 1b5806cd9..000000000
--- a/docs/testing/user/userguide/14-list-of-tcs.rst
+++ /dev/null
@@ -1,129 +0,0 @@
-.. This work is licensed under a Creative Commons Attribution 4.0 International
-.. License.
-.. http://creativecommons.org/licenses/by/4.0
-.. (c) OPNFV, Ericsson AB and others.
-
-====================
-Yardstick Test Cases
-====================
-
-Abstract
-========
-
-This chapter lists available Yardstick test cases.
-Yardstick test cases are divided in two main categories:
-
-* *Generic NFVI Test Cases* - Test Cases developed to realize the methodology
-described in :doc:`02-methodology`
-
-* *OPNFV Feature Test Cases* - Test Cases developed to verify one or more
-aspect of a feature delivered by an OPNFV Project, including the test cases
-developed for the :term:`VTC`.
-
-Generic NFVI Test Case Descriptions
-===================================
-
-.. toctree::
- :maxdepth: 1
-
- opnfv_yardstick_tc001.rst
- opnfv_yardstick_tc002.rst
- opnfv_yardstick_tc004.rst
- opnfv_yardstick_tc005.rst
- opnfv_yardstick_tc008.rst
- opnfv_yardstick_tc009.rst
- opnfv_yardstick_tc010.rst
- opnfv_yardstick_tc011.rst
- opnfv_yardstick_tc012.rst
- opnfv_yardstick_tc014.rst
- opnfv_yardstick_tc024.rst
- opnfv_yardstick_tc037.rst
- opnfv_yardstick_tc038.rst
- opnfv_yardstick_tc042.rst
- opnfv_yardstick_tc043.rst
- opnfv_yardstick_tc044.rst
- opnfv_yardstick_tc055.rst
- opnfv_yardstick_tc061.rst
- opnfv_yardstick_tc063.rst
- opnfv_yardstick_tc069.rst
- opnfv_yardstick_tc070.rst
- opnfv_yardstick_tc071.rst
- opnfv_yardstick_tc072.rst
- opnfv_yardstick_tc073.rst
- opnfv_yardstick_tc075.rst
- opnfv_yardstick_tc076.rst
-
-OPNFV Feature Test Cases
-========================
-
-H A
----
-
-.. toctree::
- :maxdepth: 1
-
- opnfv_yardstick_tc019.rst
- opnfv_yardstick_tc025.rst
- opnfv_yardstick_tc045.rst
- opnfv_yardstick_tc046.rst
- opnfv_yardstick_tc047.rst
- opnfv_yardstick_tc048.rst
- opnfv_yardstick_tc049.rst
- opnfv_yardstick_tc050.rst
- opnfv_yardstick_tc051.rst
- opnfv_yardstick_tc052.rst
- opnfv_yardstick_tc053.rst
- opnfv_yardstick_tc054.rst
-
-IPv6
-----
-
-.. toctree::
- :maxdepth: 1
-
- opnfv_yardstick_tc027.rst
-
-KVM
----
-
-.. toctree::
- :maxdepth: 1
-
- opnfv_yardstick_tc028.rst
-
-Parser
-------
-
-.. toctree::
- :maxdepth: 1
-
- opnfv_yardstick_tc040.rst
-
- StorPerf
------------
-
-.. toctree::
- :maxdepth: 1
-
- opnfv_yardstick_tc074.rst
-
-virtual Traffic Classifier
---------------------------
-
-.. toctree::
- :maxdepth: 1
-
- opnfv_yardstick_tc006.rst
- opnfv_yardstick_tc007.rst
- opnfv_yardstick_tc020.rst
- opnfv_yardstick_tc021.rst
-
-Templates
-=========
-
-.. toctree::
- :maxdepth: 1
-
- testcase_description_v2_template
- Yardstick_task_templates
-
diff --git a/docs/testing/user/userguide/14-nsb_installation.rst b/docs/testing/user/userguide/14-nsb_installation.rst
new file mode 100644
index 000000000..3eb17bbca
--- /dev/null
+++ b/docs/testing/user/userguide/14-nsb_installation.rst
@@ -0,0 +1,238 @@
+.. This work is licensed under a Creative Commons Attribution 4.0 International
+.. License.
+.. http://creativecommons.org/licenses/by/4.0
+.. (c) OPNFV, 2016-2017 Intel Corporation.
+
+Yardstick - NSB Testing -Installation
+=====================================
+
+Abstract
+--------
+
+The Network Service Benchmarking (NSB) extends the yardstick framework to do
+VNF characterization and benchmarking in three different execution
+environments viz., bare metal i.e. native Linux environment, standalone virtual
+environment and managed virtualized environment (e.g. Open stack etc.).
+It also brings in the capability to interact with external traffic generators
+both hardware & software based for triggering and validating the traffic
+according to user defined profiles.
+
+The steps needed to run Yardstick with NSB testing are:
+
+* Install Yardstick (NSB Testing).
+* Setup pod.yaml describing Test topology
+* Create the test configuration yaml file.
+* Run the test case.
+
+
+Prerequisites
+-------------
+
+Refer chapter Yardstick Instalaltion for more information on yardstick
+prerequisites
+
+Several prerequisites are needed for Yardstick(VNF testing):
+
+- Python Modules: pyzmq, pika.
+
+- flex
+
+- bison
+
+- build-essential
+
+- automake
+
+- libtool
+
+- librabbitmq-dev
+
+- rabbitmq-server
+
+- collectd
+
+- intel-cmt-cat
+
+Install Yardstick (NSB Testing)
+-------------------------------
+
+Refer chapter :doc:`04-installation` for more information on installing *Yardstick*
+
+After *Yardstick* is installed, executing the "nsb_setup.sh" script to setup
+NSB testing.
+
+::
+
+ ./nsb_setup.sh
+
+It will also automatically download all the packages needed for NSB Testing setup.
+
+System Topology:
+-----------------
+
+.. code-block:: console
+
+ +----------+ +----------+
+ | | | |
+ | | (0)----->(0) | Ping/ |
+ | TG1 | | vPE/ |
+ | | | 2Trex |
+ | | (1)<-----(1) | |
+ +----------+ +----------+
+ trafficgen_1 vnf
+
+
+OpenStack parameters and credentials
+------------------------------------
+
+Environment variables
+^^^^^^^^^^^^^^^^^^^^^
+
+Before running Yardstick (NSB Testing) it is necessary to export traffic
+generator libraries.
+
+::
+
+ source ~/.bash_profile
+
+Config yardstick conf
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+::
+
+ cp ./etc/yardstick/yardstick.conf.sample /etc/yardstick/yardstick.conf
+ vi /etc/yardstick/yardstick.conf
+
+Add trex_path and bin_path in 'nsb' section.
+
+::
+
+ [DEFAULT]
+ debug = True
+ dispatcher = influxdb
+
+ [dispatcher_influxdb]
+ timeout = 5
+ target = http://{YOUR_IP_HERE}:8086
+ db_name = yardstick
+ username = root
+ password = root
+
+ [nsb]
+ trex_path=/opt/nsb_bin/trex/scripts
+ bin_path=/opt/nsb_bin
+
+
+Config pod.yaml describing Topology
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Before executing Yardstick test cases, make sure that pod.yaml reflects the
+topology and update all the required fields.
+
+::
+
+ cp /etc/yardstick/nodes/pod.yaml.nsb.sample /etc/yardstick/nodes/pod.yaml
+
+Config pod.yaml
+::
+ nodes:
+ -
+ name: trafficgen_1
+ role: TrafficGen
+ ip: 1.1.1.1
+ user: root
+ password: r00t
+ interfaces:
+ xe0: # logical name from topology.yaml and vnfd.yaml
+ vpci: "0000:07:00.0"
+ driver: i40e # default kernel driver
+ dpdk_port_num: 0
+ local_ip: "152.16.100.20"
+ netmask: "255.255.255.0"
+ local_mac: "00:00:00:00:00:01"
+ xe1: # logical name from topology.yaml and vnfd.yaml
+ vpci: "0000:07:00.1"
+ driver: i40e # default kernel driver
+ dpdk_port_num: 1
+ local_ip: "152.16.40.20"
+ netmask: "255.255.255.0"
+ local_mac: "00:00.00:00:00:02"
+
+ -
+ name: vnf
+ role: vnf
+ ip: 1.1.1.2
+ user: root
+ password: r00t
+ host: 1.1.1.2 #BM - host == ip, virtualized env - Host - compute node
+ interfaces:
+ xe0: # logical name from topology.yaml and vnfd.yaml
+ vpci: "0000:07:00.0"
+ driver: i40e # default kernel driver
+ dpdk_port_num: 0
+ local_ip: "152.16.100.19"
+ netmask: "255.255.255.0"
+ local_mac: "00:00:00:00:00:03"
+
+ xe1: # logical name from topology.yaml and vnfd.yaml
+ vpci: "0000:07:00.1"
+ driver: i40e # default kernel driver
+ dpdk_port_num: 1
+ local_ip: "152.16.40.19"
+ netmask: "255.255.255.0"
+ local_mac: "00:00:00:00:00:04"
+ routing_table:
+ - network: "152.16.100.20"
+ netmask: "255.255.255.0"
+ gateway: "152.16.100.20"
+ if: "xe0"
+ - network: "152.16.40.20"
+ netmask: "255.255.255.0"
+ gateway: "152.16.40.20"
+ if: "xe1"
+ nd_route_tbl:
+ - network: "0064:ff9b:0:0:0:0:9810:6414"
+ netmask: "112"
+ gateway: "0064:ff9b:0:0:0:0:9810:6414"
+ if: "xe0"
+ - network: "0064:ff9b:0:0:0:0:9810:2814"
+ netmask: "112"
+ gateway: "0064:ff9b:0:0:0:0:9810:2814"
+ if: "xe1"
+
+Enable yardstick virtual environment
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Before executing yardstick test cases, make sure to activate yardstick
+python virtual environment
+
+::
+
+ source /opt/nsb_bin/yardstick_venv/bin/activate
+
+
+Run Yardstick - Network Service Testcases
+-----------------------------------------
+
+NS testing - using NSBperf CLI
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+::
+
+ source /opt/nsb_setup/yardstick_venv/bin/activate
+ PYTHONPATH: ". ~/.bash_profile"
+ cd <yardstick_repo>/yardstick/cmd
+
+ Execute command: ./NSPerf.py -h
+ ./NSBperf.py --vnf <selected vnf> --test <rfc test>
+ eg: ./NSBperf.py --vnf vpe --test tc_baremetal_rfc2544_ipv4_1flow_64B.yaml
+
+NS testing - using yardstick CLI
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+::
+
+ source /opt/nsb_setup/yardstick_venv/bin/activate
+ PYTHONPATH: ". ~/.bash_profile"
+
+Go to test case forlder type we want to execute.
+ e.g. <yardstick repo>/samples/vnf_samples/nsut/<vnf>/
+ run: yardstick --debug task start <test_case.yaml>
diff --git a/docs/testing/user/userguide/15-list-of-tcs.rst b/docs/testing/user/userguide/15-list-of-tcs.rst
new file mode 100644
index 000000000..1b5806cd9
--- /dev/null
+++ b/docs/testing/user/userguide/15-list-of-tcs.rst
@@ -0,0 +1,129 @@
+.. This work is licensed under a Creative Commons Attribution 4.0 International
+.. License.
+.. http://creativecommons.org/licenses/by/4.0
+.. (c) OPNFV, Ericsson AB and others.
+
+====================
+Yardstick Test Cases
+====================
+
+Abstract
+========
+
+This chapter lists available Yardstick test cases.
+Yardstick test cases are divided in two main categories:
+
+* *Generic NFVI Test Cases* - Test Cases developed to realize the methodology
+described in :doc:`02-methodology`
+
+* *OPNFV Feature Test Cases* - Test Cases developed to verify one or more
+aspect of a feature delivered by an OPNFV Project, including the test cases
+developed for the :term:`VTC`.
+
+Generic NFVI Test Case Descriptions
+===================================
+
+.. toctree::
+ :maxdepth: 1
+
+ opnfv_yardstick_tc001.rst
+ opnfv_yardstick_tc002.rst
+ opnfv_yardstick_tc004.rst
+ opnfv_yardstick_tc005.rst
+ opnfv_yardstick_tc008.rst
+ opnfv_yardstick_tc009.rst
+ opnfv_yardstick_tc010.rst
+ opnfv_yardstick_tc011.rst
+ opnfv_yardstick_tc012.rst
+ opnfv_yardstick_tc014.rst
+ opnfv_yardstick_tc024.rst
+ opnfv_yardstick_tc037.rst
+ opnfv_yardstick_tc038.rst
+ opnfv_yardstick_tc042.rst
+ opnfv_yardstick_tc043.rst
+ opnfv_yardstick_tc044.rst
+ opnfv_yardstick_tc055.rst
+ opnfv_yardstick_tc061.rst
+ opnfv_yardstick_tc063.rst
+ opnfv_yardstick_tc069.rst
+ opnfv_yardstick_tc070.rst
+ opnfv_yardstick_tc071.rst
+ opnfv_yardstick_tc072.rst
+ opnfv_yardstick_tc073.rst
+ opnfv_yardstick_tc075.rst
+ opnfv_yardstick_tc076.rst
+
+OPNFV Feature Test Cases
+========================
+
+H A
+---
+
+.. toctree::
+ :maxdepth: 1
+
+ opnfv_yardstick_tc019.rst
+ opnfv_yardstick_tc025.rst
+ opnfv_yardstick_tc045.rst
+ opnfv_yardstick_tc046.rst
+ opnfv_yardstick_tc047.rst
+ opnfv_yardstick_tc048.rst
+ opnfv_yardstick_tc049.rst
+ opnfv_yardstick_tc050.rst
+ opnfv_yardstick_tc051.rst
+ opnfv_yardstick_tc052.rst
+ opnfv_yardstick_tc053.rst
+ opnfv_yardstick_tc054.rst
+
+IPv6
+----
+
+.. toctree::
+ :maxdepth: 1
+
+ opnfv_yardstick_tc027.rst
+
+KVM
+---
+
+.. toctree::
+ :maxdepth: 1
+
+ opnfv_yardstick_tc028.rst
+
+Parser
+------
+
+.. toctree::
+ :maxdepth: 1
+
+ opnfv_yardstick_tc040.rst
+
+ StorPerf
+-----------
+
+.. toctree::
+ :maxdepth: 1
+
+ opnfv_yardstick_tc074.rst
+
+virtual Traffic Classifier
+--------------------------
+
+.. toctree::
+ :maxdepth: 1
+
+ opnfv_yardstick_tc006.rst
+ opnfv_yardstick_tc007.rst
+ opnfv_yardstick_tc020.rst
+ opnfv_yardstick_tc021.rst
+
+Templates
+=========
+
+.. toctree::
+ :maxdepth: 1
+
+ testcase_description_v2_template
+ Yardstick_task_templates
+
diff --git a/docs/testing/user/userguide/Yardstick_user_interface.rst b/docs/testing/user/userguide/Yardstick_user_interface.rst
deleted file mode 100644
index 9058dd46d..000000000
--- a/docs/testing/user/userguide/Yardstick_user_interface.rst
+++ /dev/null
@@ -1,29 +0,0 @@
-Yardstick User Interface
-========================
-
-This interface provides a user to view the test result
-in table format and also values pinned on to a graph.
-
-
-Command
--------
-::
-
- yardstick report generate <task-ID> <testcase-filename>
-
-
-Description
------------
-
-1. When the command is triggered using the task-id and the testcase
-name provided the respective values are retrieved from the
-database (influxdb in this particular case).
-
-2. The values are then formatted and then provided to the html
-template framed with complete html body using Django Framework.
-
-3. Then the whole template is written into a html file.
-
-The graph is framed with Timestamp on x-axis and output values
-(differ from testcase to testcase) on y-axis with the help of
-"Highcharts".
diff --git a/docs/testing/user/userguide/index.rst b/docs/testing/user/userguide/index.rst
index f99d868e9..8ac1c7bdb 100644
--- a/docs/testing/user/userguide/index.rst
+++ b/docs/testing/user/userguide/index.rst
@@ -21,11 +21,12 @@ Performance Testing User Guide (Yardstick)
06-result-store-InfluxDB
07-grafana
08-api
- 09-vtc-overview
- 10-apexlake_installation
- 11-apexlake_api
- 12-nsb-overview
- 13-nsb_installation
- 14-list-of-tcs
+ 09-yardstick_user_interface
+ 10-vtc-overview
+ 11-apexlake_installation
+ 12-apexlake_api
+ 13-nsb-overview
+ 14-nsb_installation
+ 15-list-of-tcs
glossary
references
--
cgit