-provide a procedure to execute them. In the OPNFV Danube system release,
-a Functest CLI utility is introduced for an easier execution of test procedures.
-
-**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.
-
-.. include:: ./introduction.rst
-
-The different test cases are described in the remaining sections of this document.
-
-VIM (Virtualized Infrastructure Manager)
-----------------------------------------
-
-Healthcheck tests
-^^^^^^^^^^^^^^^^^
-In Danube, healthcheck tests have been refactored and rely on SNAPS, a
-OPNFV middleware project.
-
-SNAPS stands for "SDN/NFV Application development Platform and Stack".
-SNAPS is an object-oriented OpenStack library packaged with tests that exercise
-OpenStack.
-More information on SNAPS can be found in `[13]`_
-
-Three tests are declared as healthcheck tests and can be used for gating by the
-installer, they cover functionally the tests previously done by healthcheck
-test case.
-
-The tests are:
-
-
- * *connection_check*
- * *api_check*
- * *snaps_health_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 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_health_check creates instance, allocate floating IP, connect to the VM.
-This test replaced the previous Colorado healthcheck test.
-
-Self-obviously, successful completion of the 'healthcheck' testcase is a
-necessary pre-requisite for the execution of all other test Tiers.
-
-
-vPing_ssh
-^^^^^^^^^
-
-Given the script **ping.sh**::
-
- #!/bin/sh
- while true; do
- ping -c 1 $1 2>&1 >/dev/null
- RES=$?
- if [ "Z$RES" = "Z0" ] ; then
- echo 'vPing OK'
- break
- else
- echo 'vPing KO'
- fi
- sleep 1
- done
-
-
-The goal of this test is to establish an SSH connection using a floating IP
-on the Public/External network and verify that 2 instances can talk over a Private
-Tenant network::
-
- vPing_ssh test case
- +-------------+ +-------------+
- | | | |
- | | Boot VM1 with IP1 | |
- | +------------------->| |
- | Tester | | System |
- | | Boot VM2 | Under |
- | +------------------->| Test |
- | | | |
- | | Create floating IP | |
- | +------------------->| |
- | | | |
- | | Assign floating IP | |
- | | to VM2 | |
- | +------------------->| |
- | | | |
- | | Establish SSH | |
- | | connection to VM2 | |
- | | through floating IP| |
- | +------------------->| |
- | | | |
- | | SCP ping.sh to VM2 | |
- | +------------------->| |
- | | | |
- | | VM2 executes | |
- | | ping.sh to VM1 | |
- | +------------------->| |
- | | | |
- | | If ping: | |
- | | exit OK | |
- | | else (timeout): | |
- | | exit Failed | |
- | | | |
- +-------------+ +-------------+
-
-This test can be considered as an "Hello World" example.
-It is the first basic use case which **must** work on any deployment.
-
-vPing_userdata
-^^^^^^^^^^^^^^
-
-This test case is similar to vPing_ssh but without the use of Floating IPs
-and the Public/External network to transfer the ping script.
-Instead, it uses Nova metadata service to pass it to the instance at booting time.
-As vPing_ssh, it checks that 2 instances can talk to
-each other on a Private Tenant network::
-
- vPing_userdata test case
- +-------------+ +-------------+
- | | | |
- | | Boot VM1 with IP1 | |
- | +------------------->| |
- | | | |
- | | Boot VM2 with | |
- | | ping.sh as userdata| |
- | | with IP1 as $1. | |
- | +------------------->| |
- | Tester | | System |
- | | VM2 exeutes ping.sh| Under |
- | | (ping IP1) | Test |
- | +------------------->| |
- | | | |
- | | Monitor nova | |
- | | console-log VM 2 | |
- | | If ping: | |
- | | exit OK | |
- | | else (timeout) | |
- | | exit Failed | |
- | | | |
- +-------------+ +-------------+
-
-When the second VM boots it will execute the script passed as userdata
-automatically. The ping will be detected by periodically capturing the output
-in the console-log of the second VM.
-
-
-Tempest
-^^^^^^^
-
-Tempest `[2]`_ is the reference OpenStack Integration test suite.
-It is a set of integration tests to be run against a live OpenStack cluster.
-Tempest has suites of tests for:
-
- * OpenStack API validation
- * Scenarios
- * Other specific tests useful in validating an OpenStack deployment
-
-Functest uses Rally `[3]`_ to run the Tempest suite.
-Rally generates automatically the Tempest configuration file **tempest.conf**.
-Before running the actual test cases,
-Functest creates the needed resources (user, tenant) and
-updates the appropriate parameters into the configuration file.
-
-When the Tempest suite is executed, each test duration is measured and the full
-console output is stored to a *log* file for further analysis.
-
-The Tempest testcases are distributed accross two
-Tiers:
-
- * Smoke Tier - Test Case 'tempest_smoke_serial'
- * 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'
-executes all defined Tempest tests using several concurrent threads
-(i.e. parallel mode). The number of threads activated corresponds to the number
-of available logical CPUs.
-
-The goal of the Tempest test suite is to check the basic functionalities of the
-different OpenStack components on an OPNFV fresh installation, using the
-corresponding REST API interfaces.
-
-
-Rally bench test suites
-^^^^^^^^^^^^^^^^^^^^^^^
-
-Rally `[3]`_ is a benchmarking tool that answers the question:
-
-*How does OpenStack work at scale?*
-
-The goal of this test suite is to benchmark all the different OpenStack modules and
-get significant figures that could help to define Telco Cloud KPIs.
-
-The OPNFV Rally scenarios are based on the collection of the actual Rally scenarios:
-
- * authenticate
- * cinder
- * glance
- * heat
- * keystone
- * neutron
- * nova
- * quotas
- * requests
-
-A basic SLA (stop test on errors) has been implemented.
-
-The Rally testcases are distributed accross two Tiers:
-
- * Smoke Tier - Test Case 'rally_sanity'
- * 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_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)
-
-
-SDN Controllers
----------------
-
-There are currently 3 available controllers:
-
- * OpenDaylight (ODL)
- * ONOS
- * OpenContrail (OCL)
-
-OpenDaylight
-^^^^^^^^^^^^
-
-The OpenDaylight (ODL) test suite consists of a set of basic tests inherited
-from the ODL project using the Robot `[11]`_ framework.
-The suite verifies creation and deletion of networks, subnets and ports with
-OpenDaylight and Neutron.
-
-The list of tests can be described as follows:
-
- * Basic Restconf test cases
- * Connect to Restconf URL
- * Check the HTTP code status
-
- * Neutron Reachability test cases
- * Get the complete list of neutron resources (networks, subnets, ports)
-
- * 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
-
- * 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 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