-provide a procedure to execute them. In the OPNFV Danube system release,
-a Functest CLI utility is introduced for 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
-^^^^^^^^^^^
-In Colorado release a new Tier 'healthcheck' with one testcase 'healthcheck'
-was introduced. The healthcheck testcase verifies that some basic IP connectivity
-and essential operations of OpenStack functionality over the command line are
-working correctly.
-
-In particular, the following verifications are performed:
-
- * DHCP agent functionality for IP address allocation
- * Openstack Authentication management functionality via the Keystone API
- * OpenStack Image management functionality via the Glance API
- * OpenStack Block Storage management functionality via the Cinder API
- * OpenStack Networking management functionality via the Neutron API
- * Openstack Compute management functionality via the NOVA API
-
-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
------
-
-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, 2 are part of healthcheck tier, one belongs to smoke tier.
-
-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]`_
-