Reorganize existing documents

- Align document structure with Colorado release
- follow convention used in "Python’s Style Guide for documentating"[1]

[1] https://docs.python.org/devguide/documenting.html#sections

Change-Id: Idee6ad6e68a35e3fd84ec36de480722e0259011b
JIRA: QTIP-117
Signed-off-by: Yujun Zhang <zhang.yujunz@zte.com.cn>

3 files changed, 0 insertions, 110 deletions

diff --git a/docs/templates/index.rst b/docs/templates/index.rst
deleted file mode 100644
index 1a8bc649..00000000
--- a/docs/templates/index.rst
+++ /dev/null
@@ -1,13 +0,0 @@
-.. This work is licensed under a Creative Commons Attribution 4.0 International License.
-.. http://creativecommons.org/licenses/by/4.0
-.. (c) 2015 Dell Inc.
-.. (c) 2016 ZTE Corp.
-
-**************
-QTIP Templates
-**************
-
-.. toctree::
-   :maxdepth: 2
-
-   ./testcase_description_v2_template.rst
diff --git a/docs/templates/sample_config.yaml b/docs/templates/sample_config.yaml
deleted file mode 100644
index 13f6d3fe..00000000
--- a/docs/templates/sample_config.yaml
+++ /dev/null
@@ -1,50 +0,0 @@
- ## This is a sample Config.yaml file
-
-#Scenario would define the test case scenario.
-#The benchmark key contains the benchmark to run such as dhrystone,whetstone,dpi,ssh etc.
-# Host and server list the different machines on which the benchmark would run.
-# On machines listed within hosts, the benchmarks would run in parallel.
-# On machines listed within server, the benchmarks would run when the benechmarks running on hosts have been completed.
-# This has been used  to control the folow of the testcase. For example, running the testcases on a vm vs hostmachin, we would like to run the test case serially. It should run first on the host machine and then on the vm. This testcase flow control could be used for other testcases to be developed such as those for networking.
-Scenario:
-  benchmark: dhrystone
-  host: machine_1, machine_2, virtualmachine_1
-  server:
-
-
-#Context would define the environment on which to run:
-#Host Machine keys would contain Host_Machines/ Baremetal machines to run the benchmarks on
-#e.g  in Host Machine , machine_1 and machine_2 are the bare metal machines. For each baremetal machine its IP(which should be reachable from the location on which you run QTIP), passwords and its role(host or server). If your installer is 'fuel' or 'compass' and you left baremetal machine IP empty,qtip will get compute node ip from installer automaticly.
-Context:
-  Host_Machines:
-    machine_1:
-      ip: 172.18.0.16
-      pw: Op3nStack
-      role: host
-  Virtual_Machines:
-    virtualmachine_1:
-      availability_zone: nova
-      public_network: 'net04_ext'
-      OS_image: QTIP_CentOS
-      flavor: m1.large
-      role: server
-#Proxy_Environment key was optional.If all the Machines could access the public network, no need to define Proxy_Environment.Could be used later for getting http,https proxy infos which would be setted on all the Host_Manchines and Virtual_Machines.
-  Proxy_Environment:
-    http_proxy: http://10.20.0.1:8118
-    https_proxy: http://10.20.0.1:8118
-    no_proxy: localhost,127.0.0.1,10.20.*,192.168.*
-
-# A general description of the testcase. Could be used later for reports.
-Test_Description:
-  Test_category: "Compute"
-  Benchmark: "dhrystone"
-  Overview: >
-        ''' This test will run the dhrystone benchmark in serial on machine_1 and machine_2.\n
-         if you wish to add a virtual machine add the following information under the Virtual_Machine tag
-
-        virtualmachine_1:
-          availability_zone:
-          public_network:
-          OS_image:
-          flavor:
-          role: '''
diff --git a/docs/templates/testcase_description_v2_template.rst b/docs/templates/testcase_description_v2_template.rst
deleted file mode 100644
index d68509f8..00000000
--- a/docs/templates/testcase_description_v2_template.rst
+++ /dev/null
@@ -1,47 +0,0 @@
-.. Template to be used for test case descriptions in QTIP Project.
-   Write one .rst per test case.
-   Borrowed Heavily from Yardstick
-   Upload the .rst for the test case in /docs/ directory.
-   Review in Gerrit.
-
-*************************************
-QTIP Test Case Description TCXXX
-*************************************
-
-+-----------------------------------------------------------------------------+
-|test case slogan e.g. Network throughput                                     |
-+==============+==============================================================+
-|test case id  | e.g. qtip_throughput                                         |
-+--------------+--------------------------------------------------------------+
-|metric        | what will be measured, e.g. latency                          |
-+--------------+--------------------------------------------------------------+
-|test purpose  | describe what is the purpose of the test case                |
-+--------------+--------------------------------------------------------------+
-|configuration | what .yaml file to use, state SLA if applicable, state       |
-|              | test duration, list and describe the scenario options used in|
-|              | this TC and also list the options using default values.      |
-+--------------+--------------------------------------------------------------+
-|test tool     | e.g. ping                                                    |
-+--------------+--------------------------------------------------------------+
-|references    | e.g. RFCxxx, ETSI-NFVyyy                                     |
-+--------------+--------------------------------------------------------------+
-|applicability | describe variations of the test case which can be            |
-|              | performend, e.g. run the test for different packet sizes     |
-+--------------+--------------------------------------------------------------+
-|pre-test      | describe configuration in the tool(s) used to perform        |
-|conditions    | the measurements (e.g. fio, pktgen), POD-specific            |
-|              | configuration required to enable running the test            |
-+--------------+------+----------------------------------+--------------------+
-|test sequence | step | description                      | result             |
-|              +------+----------------------------------+--------------------+
-|              |  1   | use this to describe tests that  | what happens in    |
-|              |      | require several steps e.g.       | this step          |
-|              |      | step 1 collect logs              | e.g. logs collected|
-|              +------+----------------------------------+--------------------+
-|              |  2   | remove interface                 | interface down     |
-|              +------+----------------------------------+--------------------+
-|              |  N   | what is done in step N           | what happens       |
-+--------------+------+----------------------------------+--------------------+
-|test verdict  | expected behavior, or SLA, pass/fail criteria                |
-+--------------+--------------------------------------------------------------+
-