Merge "Freeze the rally version"
[functest.git] / docs / userguide / index.rst
index 327a175..bc02776 100644 (file)
@@ -8,18 +8,28 @@ OPNFV FUNCTEST user guide
 .. toctree::
    :maxdepth: 2
 
+Version history
+===============
++------------+----------+------------------+----------------------------------+
+| **Date**   | **Ver.** | **Author**       | **Comment**                      |
+|            |          |                  |                                  |
++------------+----------+------------------+----------------------------------+
+| 2016-08-17 | 1.0.0    | Juha Haapavirta  | Colorado release                 |
+|            |          | Column Gaynor    |                                  |
++------------+----------+------------------+----------------------------------+
+| 2017-01-23 | 1.0.1    | Morgan Richomme  | Adaptations for Danube           |
+|            |          |                  |                                  |
+|            |          |                  |                                  |
++------------+----------+------------------+----------------------------------+
+
 
 Introduction
 ============
 
 The goal of this document is to describe the OPNFV Functest test cases and to
-provide a procedure to execute them. In the OPNFV Colorado system release,
+provide a procedure to execute them. In the OPNFV Danube system release,
 a Functest CLI utility is introduced for easier execution of test procedures.
 
-A overview presentation has been created for the first OPNFV Summit `[4]`_.
-
-This document is a continuation of the OPNFV Functest Configuration Guide `[1]`_.
-
 **IMPORTANT**: It is assumed here that the Functest Docker container is already
 properly deployed and that all instructions described in this guide are to be
 performed from *inside* the deployed Functest Docker container.
@@ -34,7 +44,7 @@ VIM (Virtualized Infrastructure Manager)
 Healthcheck
 ^^^^^^^^^^^
 In Colorado release a new Tier 'healthcheck' with one testcase 'healthcheck'
-is introduced. The healthcheck testcase verifies that some basic IP connectivity
+was introduced. The healthcheck testcase verifies that some basic IP connectivity
 and  essential operations of OpenStack functionality over the command line are
 working correctly.
 
@@ -90,7 +100,7 @@ Tenant network::
  |             | to VM2             |             |
  |             +------------------->|             |
  |             |                    |             |
- |             | Stablish SSH       |             |
+ |             | Establish SSH      |             |
  |             | connection to VM2  |             |
  |             | through floating IP|             |
  |             +------------------->|             |
@@ -174,7 +184,7 @@ The Tempest testcases are distributed accross two
 Tiers:
 
   * Smoke Tier - Test Case 'tempest_smoke_serial'
-  * Openstack Tier - Test case 'tempest_full_parallel'
+  * Components Tier - Test case 'tempest_full_parallel'
 
 NOTE: Test case 'tempest_smoke_serial' executes a defined set of tempest smoke
 tests with a single thread (i.e. serial mode). Test case 'tempest_full_parallel'
@@ -214,11 +224,44 @@ A basic SLA (stop test on errors) has been implemented.
 The Rally testcases are distributed accross two Tiers:
 
   * Smoke Tier - Test Case 'rally_sanity'
-  * Openstack Tier - Test case 'rally_full'
+  * Components Tier - Test case 'rally_full'
 
 NOTE: Test case 'rally_sanity' executes a limited number of Rally smoke test
 cases. Test case 'rally_full' executes the full defined set of Rally tests.
 
+SNAPS
+-----
+
+SNAPS stands for "SNA/NFV Application development Platform and Stack".
+This project seeks to develop baseline OpenStack NFV installations. It has been
+developed by Steven Pisarski and provided an object oriented library to perform
+functional and performance tests. It has been declined in several test suites in
+Functest.
+
+connection check
+^^^^^^^^^^^^^^^^
+Connection_check consists in 9 test cases (test duration < 5s) checking the
+connectivity with Glance, Keystone, Neutron, Nova and the external network.
+
+api_check
+^^^^^^^^^
+This test case verifies the retrieval of OpenStack clients: Keystone, Glance,
+Neutron and Nova and may perform some simple queries. When the config value of
+snaps.use_keystone is True, functest must have access to the cloud's private
+network.
+This suite consists in 49 tests (test duration< 2 minutes)
+
+Snaps_smoke
+^^^^^^^^^^^
+This test case contains tests that setup and destroy environments with VMs with
+and without Floating IPs with a newly created user and project. Set the config
+value snaps.use_floating_ips (True|False) to toggle this functionality. When
+the config value of snaps.use_keystone is True, functest must have access
+the cloud's private network.
+This suite consists in 38 tests (test duration < 10 minutes)
+
+More information on SNAPS can be found in  `[13]`_
+
 
 SDN Controllers
 ---------------
@@ -238,42 +281,41 @@ OpenDaylight and Neutron.
 
 The list of tests can be described as follows:
 
- * Restconf.basic: Get the controller modules via Restconf
- * Neutron.Networks
+ * Basic Restconf test cases
+   * Connect to Restconf URL
+   * Check the HTTP code status
 
-   * Check OpenStack Networks :: Checking OpenStack Neutron for known networks
-   * Check OpenDaylight Networks :: Checking OpenDaylight Neutron API
-   * Create Network :: Create new network in OpenStack
-   * Check Network :: Check Network created in OpenDaylight
-   * Neutron.Networks :: Checking Network created in OpenStack are pushed
+ * Neutron Reachability test cases
+   * Get the complete list of neutron resources (networks, subnets, ports)
 
- * Neutron.Subnets
+ * Neutron Network test cases
+   * Check OpenStack networks
+   * Check OpenDaylight networks
+   * Create a new network via OpenStack and check the HTTP status code returned by Neutron
+   * Check that the network has also been successfully created in OpenDaylight
 
  * Check OpenStack Subnets :: Checking OpenStack Neutron for known Subnets
-   * Check OpenDaylight subnets :: Checking OpenDaylight Neutron API
-   * Create New subnet :: Create new subnet in OpenStack
-   * Check New subnet :: Check new subnet created in OpenDaylight
-   * Neutron.Subnets :: Checking Subnets created in OpenStack are pushed
* Neutron Subnet test cases
+   * Check OpenStack subnets
+   * Check OpenDaylight subnets
+   * Create a new subnet via OpenStack and check the HTTP status code returned by Neutron
+   * Check that the subnet has also been successfully created in OpenDaylight
 
- * Neutron.Ports
+ * Neutron Port test cases
+   * Check OpenStack Neutron for known ports
+   * Check OpenDaylight ports
+   * Create a new port via OpenStack and check the HTTP status code returned by Neutron
+   * Check that the new port has also been successfully created in OpenDaylight
 
-   * Check OpenStack ports :: Checking OpenStack Neutron for known ports
-   * Check OpenDaylight ports :: Checking OpenDaylight Neutron API
-   * Create New Port :: Create new port in OpenStack
-   * Check New Port :: Check new subnet created in OpenDaylight
-   * Neutron.Ports :: Checking Port created in OpenStack are pushed
+ * Delete operations
+   * Delete the port previously created via OpenStack
+   * Check that the port has been also succesfully deleted in OpenDaylight
+   * Delete previously subnet created via OpenStack
+   * Check that the subnet has also been successfully deleted in OpenDaylight
+   * Delete the network created via OpenStack
+   * Check that the network has also been succesfully deleted in OpenDaylight
 
- * Delete Ports
-
-   * Delete previously created subnet in OpenStack
-   * Check subnet deleted in OpenDaylight
-   * Check subnet deleted in OpenStack
-
- * Delete network
-
-   * Delete previously created network in OpenStack
-   * Check network deleted in OpenDaylight
-   * Check network deleted in OpenStack
+Note: the checks in OpenDaylight are based on the returned HTTP status
+code returned by OpenDaylight.
 
 
 ONOS
@@ -320,70 +362,23 @@ The test cases are described as follows:
    * Delete External Gateway: Delete the External Gateway and check that it is
      'NULL' in ONOS
 
-Open Contrail
-^^^^^^^^^^^^^
-**TODO:**
-
-
 
 Features
 --------
 
-Doctor
-^^^^^^
-
-**TODO:**
-
+Please refer to the dedicated feature user guides for details:
 
-
-Promise
-^^^^^^^
-
-Promise provides a basic set of test cases as part of the deliverable.
-
-The available 33 test cases can be grouped into 7 test suites:
-
-    #. Add a new OpenStack provider into resource pool: Registers
-       OpenStack into a new resource pool and adds more capacity associated
-       with this pool.
-
-    #. Allocation without reservation: Creates a new server in OpenStack
-       and adds a new allocation record in Promise shim-layer.
-
-    #. Allocation using reservation for immediate use: Creates a resource
-       reservation record with no start/end time and immediately creates a new
-       server in OpenStack and add a new allocation record in Promise
-       shim-layer.
-
-    #. Reservation for future use: Creates a resource reservation record
-       for a future start time, queries, modifies and cancels the newly created
-       reservation.
-
-    #. Capacity planning: Decreases and increases the available capacity
-       from a provider in the future and queries the available collections and
-       utilizations.
-
-    #. Reservation with conflict: Tries to create reservations for
-       immediate and future use with conflict.
-
-    #. Cleanup test allocations: Destroys all allocations in OpenStack.
-
-
-bgpvpn
-^^^^^^
-Many telecom network functions are relying on layer-3 infrastructure services,
-within a VNF between components, or towards existing external networks.
-In many cases, these external networks are implemented in MPLS/BGP technology in
-existing service provider wide-area-networks (WAN). This proven technology
-provides a good mechanism for inter-operation of a NFV Infrastructure (NFVI)
-and WAN.
-
-The SDNVPN project defined a 'bgpvpn' test suite.
-This 'bgpvpn' test suite deals with 2 Tempest cases dedicated to the test of
-the OpenStack 'bgpvpn' API:
-
-  * test_create_bgpvpn
-  * test_create_bgpvpn_as_non_admin_fail
+ * bgpvpn: http://artifacts.opnfv.org/sdnvpn/danube/docs/userguide/index.html
+ * copper: http://artifacts.opnfv.org/copper/danube/docs/userguide/index.html
+ * doctor: http://artifacts.opnfv.org/doctor/danube/userguide/index.html
+ * domino: http://artifacts.opnfv.org/domino/docs/userguide-single/index.html
+ * moon: http://artifacts.opnfv.org/moon/docs/userguide/index.html
+ * multisites: http://artifacts.opnfv.org/multisite/docs/userguide/index.html
+ * onos-sfc: http://artifacts.opnfv.org/onosfw/danube/userguide/index.html
+ * odl-sfc: http://artifacts.opnfv.org/sfc/danube/userguide/index.html
+ * promise: http://artifacts.opnfv.org/danube/colorado/docs/userguide/index.html
+ * security_scan: http://artifacts.opnfv.org/security_scan/colorado/docs/userguide/index.html
+ * TODO
 
 security_scan
 ^^^^^^^^^^^^^
@@ -391,11 +386,12 @@ security_scan
 Security Scanning, is a project to insure security compliance and vulnerability
 checks, as part of an automated CI / CD platform delivery process.
 
-The project makes use of the existing SCAP format[6] to perform deep scanning of
-NFVi nodes, to insure they are hardened and free of known CVE reported vulnerabilities.
+The project makes use of the existing SCAP format `[6]`_ to perform deep
+scanning of NFVI nodes, to insure they are hardened and free of known CVE
+reported vulnerabilities.
 
 The SCAP content itself, is then consumed and run using an upstream opensource tool
-known as OpenSCAP[7].
+known as OpenSCAP `[7]`_.
 
 The OPNFV Security Group have developed the code that will called by the OPNFV Jenkins
 build platform, to perform a complete scan. Resulting reports are then copied to the
@@ -406,7 +402,7 @@ The current work flow is as follows:
   * Jenkins Build Initiated
   * security_scan.py script is called, and a config file is passed to the script as
     an argument.
-  * The IP addresses of each NFVi node (compute / control), is gathered.
+  * The IP addresses of each NFVi node (compute / control) are gathered
   * A scan profile is matched to the node type.
   * The OpenSCAP application is remotely installed onto each target node gathered
     on step 3, using upstream packaging (rpm and .deb).
@@ -415,8 +411,9 @@ The current work flow is as follows:
   * If the config file value 'clean' is set to 'True' then the application installed in
     step 5 is removed, and all reports created at step 6 are deleted.
 
-At present, only the Apex installer is supported, with support for other installers due
-within D-release.
+Security scan is supported by Apex, TODO....
+
+
 
 VNF
 ---
@@ -429,8 +426,8 @@ architectural framework for delivering IP multimedia services.
 
 vIMS has been integrated in Functest to demonstrate the capability to deploy a
 relatively complex NFV scenario on the OPNFV platform. The deployment of a complete
-functional VNF allows the test of most of the
-essential functions needed for a NFV platform.
+functional VNF allows the test of most of the essential functions needed for a
+NFV platform.
 
 The goal of this test suite consists of:
 
@@ -446,16 +443,71 @@ The Clearwater architecture is described as follows:
    :alt: vIMS architecture
 
 
+parser
+^^^^^^
+
+See parser user guide for details: `[12]`_
+
+
 .. include:: ./runfunctest.rst
 
 
 Test results
 ============
 
-Note that the results are documented per scenario basis. Although most of the test
-cases might show the same output, some of them are not supported by
-certain scenarios. Please select the appropriate scenario and compare the results
-to that referenced in the documentation.
+Manual testing
+--------------
+
+In manual mode test results are displayed in the console and result files
+are put in /home/opnfv/functest/results.
+
+Automated testing
+--------------
+
+In automated mode, test results are displayed in jenkins logs, a summary is provided
+at the end of the job and can be described as follow::
+
+ +==================================================================================================================================================+
+ |                                                                FUNCTEST REPORT                                                                   |
+ +==================================================================================================================================================+
+ |                                                                                                                                                  |
+ |  Deployment description:                                                                                                                         |
+ |    INSTALLER: fuel                                                                                                                               |
+ |    SCENARIO:  os-odl_l2-nofeature-ha                                                                                                             |
+ |    BUILD TAG: jenkins-functest-fuel-baremetal-daily-master-324                                                                                   |
+ |    CI LOOP:   daily                                                                                                                              |
+ |                                                                                                                                                  |
+ +=========================+===============+============+===============+===========================================================================+
+ | TEST CASE               | TIER          | DURATION   | RESULT        | URL                                                                       |
+ +=========================+===============+============+===============+===========================================================================+
+ | healthcheck             | healthcheck   | 03:07      | PASS          |                                                                           |
+ +-------------------------+---------------+------------+---------------+---------------------------------------------------------------------------+
+ | vping_ssh               | smoke         | 00:56      | PASS          | http://testresults.opnfv.org/test/api/v1/results/57ac13d79377c54b278bd4c1 |
+ +-------------------------+---------------+------------+---------------+---------------------------------------------------------------------------+
+ | vping_userdata          | smoke         | 00:41      | PASS          | http://testresults.opnfv.org/test/api/v1/results/57ac14019377c54b278bd4c2 |
+ +-------------------------+---------------+------------+---------------+---------------------------------------------------------------------------+
+ | tempest_smoke_serial    | smoke         | 16:05      | FAIL          | http://testresults.opnfv.org/test/api/v1/results/57ac17ca9377c54b278bd4c3 |
+ +-------------------------+---------------+------------+---------------+---------------------------------------------------------------------------+
+ | rally_sanity            | smoke         | 12:19      | PASS          | http://testresults.opnfv.org/test/api/v1/results/57ac1aad9377c54b278bd4cd |
+ +-------------------------+---------------+------------+---------------+---------------------------------------------------------------------------+
+ | odl                     | sdn_suites    | 00:24      | PASS          | http://testresults.opnfv.org/test/api/v1/results/57ac1ad09377c54b278bd4ce |
+ +-------------------------+---------------+------------+---------------+---------------------------------------------------------------------------+
+ | promise                 | features      | 00:41      | PASS          | http://testresults.opnfv.org/test/api/v1/results/57ac1ae59377c54b278bd4cf |
+ +-------------------------+---------------+------------+---------------+---------------------------------------------------------------------------+
+
+Results are automatically pushed to the test results database, some additional
+result files are pushed to OPNFV artifact web sites.
+
+Based on the results stored in the result database, a `Functest reporting`_
+portal is also automatically updated. This portal provides information on:
+
+ * The overall status per scenario and per installer
+ * Tempest: Tempest test case including reported errors per scenario and installer
+ * vIMS: vIMS details per scenario and installer
+
+.. figure:: ../images/functest-reporting-status.png
+   :align: center
+   :alt: Functest reporting portal Fuel status page
 
 
 Test Dashboard
@@ -470,7 +522,7 @@ Based on results collected in CI, a test dashboard is dynamically generated.
 References
 ==========
 
-.. _`[1]`: http://artifacts.opnfv.org/functest/docs/configguide/#
+.. _`[1]`: http://artifacts.opnfv.org/functest/colorado/docs/configguide/#
 .. _`[2]`: http://docs.openstack.org/developer/tempest/overview.html
 .. _`[3]`: https://rally.readthedocs.org/en/latest/index.html
 .. _`[4]`: http://events.linuxfoundation.org/sites/events/files/slides/Functest%20in%20Depth_0.pdf
@@ -479,6 +531,8 @@ References
 .. _`[7]`: https://github.com/OpenSCAP/openscap
 .. _`[9]`: https://git.opnfv.org/cgit/functest/tree/testcases/VIM/OpenStack/CI/libraries/os_defaults.yaml
 .. _`[11]`: http://robotframework.org/
+.. _`[12]`: http://artifacts.opnfv.org/parser/colorado/docs/userguide/index.html
+.. _`[13]`: TODO URL doc SNAPS
 
 OPNFV main site: opnfvmain_.
 
@@ -492,3 +546,4 @@ IRC support chan: #opnfv-testperf
 .. _`Rally installation procedure`: https://rally.readthedocs.org/en/latest/tutorial/step_0_installation.html
 .. _`config_test.py` : https://git.opnfv.org/cgit/functest/tree/testcases/config_functest.py
 .. _`config_functest.yaml` : https://git.opnfv.org/cgit/functest/tree/testcases/config_functest.yaml
+.. _`Functest reporting`: http://testresults.opnfv.org/reporting/functest/release/colorado/index-status-fuel.html