[docs] Documentation for BNG PPPoE RFC2544 test cases

[yardstick.git] / docs / testing / user / userguide / 03-architecture.rst

diff --git a/docs/testing/user/userguide/03-architecture.rst b/docs/testing/user/userguide/03-architecture.rst
index 03bf00f..62250d6 100755 (executable)
--- a/docs/testing/user/userguide/03-architecture.rst
+++ b/docs/testing/user/userguide/03-architecture.rst
@@ -9,8 +9,9 @@ Architecture
 
 Abstract
 ========
 
 Abstract
 ========

-This chapter describes the yardstick framework software architecture. we will introduce it from Use-Case View,
-Logical View, Process View and Deployment View. More technical details will be introduced in this chapter.
+This chapter describes the yardstick framework software architecture. We will
+introduce it from Use-Case View, Logical View, Process View and Deployment
+View. More technical details will be introduced in this chapter.

 
 Overview
 ========
 
 Overview
 ========


@@ -23,8 +24,8 @@ files. Yardstick is inspired by Rally. Yardstick is intended to run on a
 computer with access and credentials to a cloud. The test case is described
 in a configuration file given as an argument.
 
 computer with access and credentials to a cloud. The test case is described
 in a configuration file given as an argument.
 

-How it works: the benchmark task configuration file is parsed and converted into
-an internal model. The context part of the model is converted into a Heat
+How it works: the benchmark task configuration file is parsed and converted
+into an internal model. The context part of the model is converted into a Heat

 template and deployed into a stack. Each scenario is run using a runner, either
 serially or in parallel. Each runner runs in its own subprocess executing
 commands in a VM using SSH. The output of each scenario is written as json
 template and deployed into a stack. Each scenario is run using a runner, either
 serially or in parallel. Each runner runs in its own subprocess executing
 commands in a VM using SSH. The output of each scenario is written as json


@@ -43,13 +44,15 @@ names, image names, affinity rules and network configurations. A context is
 converted into a simplified Heat template, which is used to deploy onto the
 Openstack environment.
 
 converted into a simplified Heat template, which is used to deploy onto the
 Openstack environment.
 

-**Data** - Output produced by running a benchmark, written to a file in json format
+**Data** - Output produced by running a benchmark, written to a file in json
+format

 
 **Runner** - Logic that determines how a test scenario is run and reported, for
 example the number of test iterations, input value stepping and test duration.
 Predefined runner types exist for re-usage, see `Runner types`_.
 
 
 **Runner** - Logic that determines how a test scenario is run and reported, for
 example the number of test iterations, input value stepping and test duration.
 Predefined runner types exist for re-usage, see `Runner types`_.
 

-**Scenario** - Type/class of measurement for example Ping, Pktgen, (Iperf, LmBench, ...)
+**Scenario** - Type/class of measurement for example Ping, Pktgen, (Iperf,
+LmBench, ...)

 
 **SLA** - Relates to what result boundary a test case must meet to pass. For
 example a latency limit, amount or ratio of lost packets and so on. Action
 
 **SLA** - Relates to what result boundary a test case must meet to pass. For
 example a latency limit, amount or ratio of lost packets and so on. Action


@@ -128,8 +131,8 @@ Snippet of an Iteration runner configuration:
 Use-Case View
 =============
 Yardstick Use-Case View shows two kinds of users. One is the Tester who will
 Use-Case View
 =============
 Yardstick Use-Case View shows two kinds of users. One is the Tester who will

-do testing in cloud, the other is the User who is more concerned with test result
-and result analyses.
+do testing in cloud, the other is the User who is more concerned with test
+result and result analyses.

 
 For testers, they will run a single test case or test case suite to verify
 infrastructure compliance or bencnmark their own infrastructure performance.
 
 For testers, they will run a single test case or test case suite to verify
 infrastructure compliance or bencnmark their own infrastructure performance.


@@ -187,9 +190,9 @@ run test measurement scripts through the ssh tunnel. After all TestScenaio
 is finished, TaskCommands will undeploy the heat stack. Then the whole test is
 finished.
 
 is finished, TaskCommands will undeploy the heat stack. Then the whole test is
 finished.
 

-.. image:: images/Logical_view.png
+.. image:: images/Yardstick_framework_architecture_in_D.png

    :width: 800px
    :width: 800px

-   :alt: Yardstick Logical View
+   :alt: Yardstick framework architecture in Danube

 
 Process View (Test execution flow)
 ==================================
 
 Process View (Test execution flow)
 ==================================


@@ -236,31 +239,31 @@ Yardstick Directory structure
 
 **yardstick/** - Yardstick main directory.
 
 
 **yardstick/** - Yardstick main directory.
 

-*ci/* - Used for continuous integration of Yardstick at different PODs and
+*tests/ci/* - Used for continuous integration of Yardstick at different PODs and

         with support for different installers.
 
 *docs/* - All documentation is stored here, such as configuration guides,
         with support for different installers.
 
 *docs/* - All documentation is stored here, such as configuration guides,

-          user guides and Yardstick descriptions.
+          user guides and Yardstick test case descriptions.

 
 *etc/* - Used for test cases requiring specific POD configurations.
 
 *samples/* - test case samples are stored here, most of all scenario and
 
 *etc/* - Used for test cases requiring specific POD configurations.
 
 *samples/* - test case samples are stored here, most of all scenario and

-             feature's samples are shown in this directory.
+             feature samples are shown in this directory.

 
 

-*tests/* - Here both Yardstick internal tests (*functional/* and *unit/*) as
-           well as the test cases run to verify the NFVI (*opnfv/*) are stored.
-           Also configurations of what to run daily and weekly at the different
-           PODs is located here.
+*tests/* - The test cases run to verify the NFVI (*opnfv/*) are stored here.
+           The configurations of what to run daily and weekly at the different
+           PODs are also located here.

 
 

-*tools/* - Currently contains tools to build image for VMs which are deployed
-           by Heat. Currently contains how to build the yardstick-trusty-server
-           image with the different tools that are needed from within the image.
+*tools/* - Contains tools to build image for VMs which are deployed by Heat.
+           Currently contains how to build the yardstick-image with the
+           different tools that are needed from within the image.

 
 *plugin/* - Plug-in configuration files are stored here.
 
 
 *plugin/* - Plug-in configuration files are stored here.
 

-*vTC/* - Contains the files for running the virtual Traffic Classifier tests.
-
-*yardstick/* - Contains the internals of Yardstick: Runners, Scenario, Contexts,
-               CLI parsing, keys, plotting tools, dispatcher, plugin
+*yardstick/* - Contains the internals of Yardstick: :term:`Runners <runner>`,
+               :term:`Scenarios <scenario>`, :term:`Contexts <context>`, CLI
+               parsing, keys, plotting tools, dispatcher, plugin

                install/remove scripts and so on.
 
                install/remove scripts and so on.
 

+*yardstick/tests* - The Yardstick internal tests (*functional/* and *unit/*)
+                    are stored here.