Functest User Guide¶

Introduction¶

The goal of this document is to describe the OPNFV Functest test cases and to provide a procedure to execute them.

IMPORTANT: It is assumed here that Functest has been properly deployed following the installation guide procedure [1].

Overview of the Functest suites¶

Functest is the OPNFV project primarily targeting functional testing. In the Continuous Integration pipeline, it is launched after an OPNFV fresh installation to validate and verify the basic functions of the infrastructure.

The current list of test suites can be distributed over 4 main domains:

VIM (Virtualised Infrastructure Manager)
Controllers (i.e. SDN Controllers)
Features
VNF (Virtual Network Functions)

Functest test suites are also distributed in the OPNFV testing categories: healthcheck, smoke, features, components, performance, VNF, Stress tests.

All the Healthcheck and smoke tests of a given scenario must be succesful to validate the scenario for the release.

Domain	Tier	Test case	Comments
VIM	healthcheck	connection _check	Check OpenStack connectivity through SNAPS framework
		api_check	Check OpenStack API through SNAPS framework
		snaps_health _check	basic instance creation, check DHCP
	smoke	vping_ssh	NFV “Hello World” using an SSH connection to a destination VM over a created floating IP address on the SUT Public / External network. Using the SSH connection a test script is then copied to the destination VM and then executed via SSH. The script will ping another VM on a specified IP address over the SUT Private Tenant network
		vping_userdata	Uses Ping with given userdata to test intra-VM connectivity over the SUT Private Tenant network. The correct operation of the NOVA Metadata service is also verified in this test
		tempest_smoke _serial	Generate and run a relevant Tempest Test Suite in smoke mode. The generated test set is dependent on the OpenStack deployment environment
		rally_sanity	Run a subset of the OpenStack Rally Test Suite in smoke mode
		snaps_smoke	Run the SNAPS-OO integration tests
		refstack _defcore	Reference RefStack suite tempest selection for NFV
	components	tempest_full _parallel	Generate and run a full set of the OpenStack Tempest Test Suite. See the OpenStack reference test suite [2]. The generated test set is dependent on the OpenStack deployment environment
	components	rally_full	Run the OpenStack testing tool benchmarking OpenStack modules See the Rally documents [3]
Controllers	smoke	odl	Opendaylight Test suite Limited test suite to check the basic neutron (Layer 2) operations mainly based on upstream testcases. See below for details
		odl_netvirt	Test Suite for the OpenDaylight SDN Controller when the NetVirt features are installed. It integrates some test suites from upstream using Robot as the test framework
		fds	Test Suite for the OpenDaylight SDN Controller when the GBP features are installed. It integrates some test suites from upstream using Robot as the test framework
Features	features	bgpvpn	Implementation of the OpenStack bgpvpn API from the SDNVPN feature project. It allows for the creation of BGP VPNs. See SDNVPN User Guide for details
		doctor	Doctor platform, as of Colorado release, provides the three features: * Immediate Notification * Consistent resource state awareness for compute host down * Valid compute host status given to VM owner See Doctor User Guide for details
		domino	Domino provides TOSCA template distribution service for network service and VNF descriptors among MANO components e.g., NFVO, VNFM, VIM, SDN-C, etc., as well as OSS/BSS functions. See Domino User Guide for details
		odl-sfc	SFC testing for odl scenarios See SFC User Guide for details
		parser	Parser is an integration project which aims to provide placement/deployment templates translation for OPNFV platform, including TOSCA -> HOT, POLICY -> TOSCA and YANG -> TOSCA. it deals with a fake vRNC. See Parser User Guide for details
		promise	Resource reservation and management project to identify NFV related requirements and realize resource reservation for future usage by capacity management of resource pools regarding compute, network and storage. See Promise User Guide for details
VNF	vnf	cloudify_ims	Example of a real VNF deployment to show the NFV capabilities of the platform. The IP Multimedia Subsytem is a typical Telco test case, referenced by ETSI. It provides a fully functional VoIP System
		orchestra openims	OpenIMS deployment using Openbaton orchestrator
		orchestra cleawaterims	Cleawater IMS deployment using Openbaton orchestrator
		vyos_vrouter	vRouter testing
		cloudify_ims perf	Based on cloudify_ims test case cloudify_ims_perf substitutes the signaling test suite by an automatic deployment of an Ixia loader and generic SIP stress tests. This work has been initiated during the plugfest and allows realistic load tests on top of cloudify_ims. Please note that this test is available but not declared in testcases.yaml as it requires access to proprietary resources (Ixia loader)

As shown in the above table, Functest is structured into different ‘domains’, ‘tiers’ and ‘test cases’. Each ‘test case’ usually represents an actual ‘Test Suite’ comprised -in turn- of several test cases internally.

Test cases also have an implicit execution order. For example, if the early ‘healthcheck’ Tier testcase fails, or if there are any failures in the ‘smoke’ Tier testcases, there is little point to launch a full testcase execution round.

In Danube, we merged smoke and sdn controller tiers in smoke tier.

An overview of the Functest Structural Concept is depicted graphically below:

Some of the test cases are developed by Functest team members, whereas others are integrated from upstream communities or other OPNFV projects. For example, Tempest is the OpenStack integration test suite and Functest is in charge of the selection, integration and automation of those tests that fit suitably to OPNFV.

The Tempest test suite is the default OpenStack smoke test suite but no new test cases have been created in OPNFV Functest.

The results produced by the tests run from CI are pushed and collected into a NoSQL database. The goal is to populate the database with results from different sources and scenarios and to show them on a Functest Dashboard. A screenshot of a live Functest Dashboard is shown below:

Basic components (VIM, SDN controllers) are tested through their own suites. Feature projects also provide their own test suites with different ways of running their tests.

The notion of domain has been introduced in the description of the test cases stored in the Database. This parameters as well as possible tags can be used for the Test case catalog.

vIMS test case was integrated to demonstrate the capability to deploy a relatively complex NFV scenario on top of the OPNFV infrastructure.

Functest considers OPNFV as a black box. OPNFV offers a lot of potential combinations (which may change from one version to another):

3 controllers (OpenDaylight, ONOS, OpenContrail)

5 installers (Apex, Compass, Daisy, Fuel, Joid)

Most of the tests are runnable by any combination, but some tests might have restrictions imposed by the utilized installers or due to the available deployed features. The system uses the environment variables (INSTALLER_TYPE and DEPLOY_SCENARIO) to automatically determine the valid test cases, for each given environment.

A convenience Functest CLI utility is also available to simplify setting up the Functest evironment, management of the OpenStack environment (e.g. resource clean-up) and for executing tests. The Functest CLI organised the testcase into logical Tiers, which contain in turn one or more testcases. The CLI allows execution of a single specified testcase, all test cases in a specified Tier, or the special case of execution of ALL testcases. The Functest CLI is introduced in more details in next section.

The different test cases are described in the remaining sections of this document.

VIM (Virtualized Infrastructure Manager)¶

Healthcheck tests¶

Since Danube, healthcheck tests have been refactored and rely on SNAPS, an 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
ping -c 1 $1 2>&1 >/dev/null
RES=$?
if [ "Z$RES" = "Z0" ] ; then
    echo 'vPing OK'
else
    echo 'vPing KO'
fi

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 across 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

ceilometer

A basic SLA (stop test on errors) has been implemented.

The Rally testcases are distributed across 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.

Refstack-client to run OpenStack interop testcases¶

Refstack-client [8] is a command line utility that allows you to execute Tempest test runs based on configurations you specify. It is the official tool to run Openstack Interop (previously known as Defcore) testcases [9], which focus on testing interoperability between OpenStack clouds.

Refstack-client is integrated in Functest, consumed by Dovetail, which intends to define and provide a set of OPNFV related validation criteria that will provide input for the evaluation of the use of OPNFV trademarks. This progress is under the guideline of Compliance Verification Program(CVP).

Running methods¶

Two running methods are provided after refstack-client integrated into Functest, Functest command line and manually, respectively.

By default, for Defcore test cases run by Functest command line, are run followed with automatically generated configuration file, i.e., refstack_tempest.conf. In some circumstances, the automatic configuration file may not quite satisfied with the SUT, Functest also inherits the refstack-client command line and provides a way for users to set its configuration file according to its own SUT manually.

command line

Inside the Functest container, first to prepare Functest environment:

functest env prepare

then to run default defcore testcases by using refstack-client:

functest testcase run refstack_defcore

In OPNFV Continuous Integration(CI) system, the command line method is used.

manually

Prepare the tempest configuration file and the testcases want to run with the SUT, run the testcases with:

./refstack-client test -c <Path of the tempest configuration file to use> -v --test-list <Path or URL of test list>

using help for more information:

./refstack-client --help
./refstack-client test --help

Reference tempest configuration¶

command line method

When command line method is used, the default tempest configuration file is generated by Rally.

manually

When running manually is used, recommended way to generate tempest configuration file is:

cd /usr/lib/python2.7/site-packages/functest/opnfv_tests/openstack/refstack_client
python tempest_conf.py

a file called tempest.conf is stored in the current path by default, users can do some adjustment according to the SUT:

vim refstack_tempest.conf

a reference article can be used [15].

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. Please note that When the configuration 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¶

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

Delete operations * Delete the port previously created via OpenStack * Check that the port has been also successfully 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 successfully deleted in OpenDaylight

Note: the checks in OpenDaylight are based on the returned HTTP status code returned by OpenDaylight.

Features¶

Functest has been supporting several feature projects since Brahpamutra:

Test	Brahma	Colorado	Danube	Euphrates
barometer			X	X
bgpvpn		X	X	X
copper		X
doctor	X	X	X	X
domino		X	X	X
fds			X	X
moon		X
multisite		X	X
netready			X
odl_sfc		X	X	X
opera			X
orchestra			X	X
parser			X	X
promise	X	X	X	X
security_scan		X	X

Please refer to the dedicated feature user guides for details.

VNF¶

cloudify_ims¶

The IP Multimedia Subsystem or IP Multimedia Core Network Subsystem (IMS) is an 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.

The goal of this test suite consists of:

deploy a VNF orchestrator (Cloudify)

deploy a Clearwater vIMS (IP Multimedia Subsystem) VNF from this orchestrator based on a TOSCA blueprint defined in [5]

run suite of signaling tests on top of this VNF

The Clearwater architecture is described as follows:

cloudify_ims_perf¶

This testcase extends the cloudify_ims test case. The first part is similar but the testing part is different. The testing part consists in automating a realistic signaling load on the vIMS using an Ixia loader (proprietary tools)

You need to have access to an Ixia licence server defined in the configuration

file and have ixia image locally.

This test case is available but not declared in testcases.yaml. The declaration of the testcase is simple, connect to your functest-vnf docker, add the following section in /usr/lib/python2.7/site-packacges/functest/ci/testcases.yaml:

-
    case_name: cloudify_ims_perf
    project_name: functest
    criteria: 80
    blocking: false
    description: >-
        Stress tests based on Cloudify. Ixia loader images and access to Ixia
        server license.
    dependencies:
        installer: ''
        scenario: 'os-nosdn-nofeature-ha'
    run:
        module: 'functest.opnfv_tests.vnf.ims.cloudify_ims_perf'
        class: 'CloudifyImsPerf'

orchestra_openims¶

Orchestra test case deals with the deployment of OpenIMS with OpenBaton orchestrator.

orchestra_clearwaterims¶

Orchestra test case deals with the deployment of Clearwater vIMS with OpenBaton orchestrator.

vyos-vrouter¶

This test case deals with the deployment and the test of vyos vrouter with Cloudify orchestrator. The test case can do testing for interchangeability of BGP Protocol using vyos.

The Workflow is as follows:

Deploy

Deploy VNF Testing topology by Cloudify using blueprint.
Configuration

Setting configuration to Target VNF and reference VNF using ssh
Run

Execution of test command for test item written YAML format file. Check VNF status and behavior.
Reporting

Output of report based on result using JSON format.

The vyos-vrouter architecture is described in [14]

Executing Functest suites¶

As mentioned in the configuration guide [1], Alpine docker containers have been introduced in Euphrates. Tier containers have been created. Assuming that you pulled the container and your environement is ready, you can simply run the tiers by typing (e.g. with functest-healthcheck):

sudo docker run --env-file env \
    -v $(pwd)/openstack.creds:/home/opnfv/functest/conf/openstack.creds  \
    -v $(pwd)/images:/home/opnfv/functest/images  \
    opnfv/functest-healthcheck

You should get:

+----------------------------+------------------+---------------------+------------------+----------------+
|         TEST CASE          |     PROJECT      |         TIER        |     DURATION     |     RESULT     |
+----------------------------+------------------+---------------------+------------------+----------------+
|      connection_check      |     functest     |     healthcheck     |      00:02       |      PASS      |
|         api_check          |     functest     |     healthcheck     |      03:19       |      PASS      |
|     snaps_health_check     |     functest     |     healthcheck     |      00:46       |      PASS      |
+----------------------------+------------------+---------------------+------------------+----------------+

You can run functest-healcheck, functest-smoke, functest-features, functest-components and functest-vnf.

The result tables show the results by test case, it can be:

* PASS
* FAIL
* SKIP: if the scenario/installer does not support the test case

Manual run¶

If you want to run the test step by step, you may add docker option then run the different commands within the docker.

Considering the healthcheck example, running functest manaully means:

sudo docker run -ti --env-file env \
  -v $(pwd)/openstack.creds:/home/opnfv/functest/conf/openstack.creds  \
  -v $(pwd)/images:/home/opnfv/functest/images  \
  opnfv/functest-healthcheck /bin/bash

The docker prompt shall be returned. Then within the docker run the following commands:

$ source /home/opnfv/functest/conf/openstack.creds

Prepare environment¶

Prior to commencing the Functest environment preparation, we can check the initial status of the environment. Issue the functest env status command at the prompt:

# functest env status
# Functest environment is not installed.

To prepare the Functest docker container for test case execution, type:

# functest env prepare
# ...
# Functest environment ready to run tests.

you may also type prepare_env instead of functest env prepare.

To list some basic information about an already prepared Functest docker container environment, issue the functest env show at the prompt:

bash-4.3# functest env show
+------------------------------+---------------------------------+
|     FUNCTEST ENVIRONMENT     |              VALUE              |
+------------------------------+---------------------------------+
|            STATUS            |              ready              |
|           SCENARIO           |     os-nosdn-nofeature-noha     |
|          DEBUG FLAG          |              false              |
|          BUILD_TAG           |               None              |
|          INSTALLER           |              compass            |
|             POD              |           huawei-pod1           |
+------------------------------+---------------------------------+

See configuration guide for details on Functest environnement variables.

Tier¶

Each Alpine container provided on the docker hub matches with a tier. The following commands are available:

# functest tier list
  - 0. healthcheck:
  ['connection_check', 'api_check', 'snaps_health_check']
# functest tier show healthcheck
+---------------------+---------------+--------------------------+-------------------------------------------------+------------------------------------+
|        TIERS        |     ORDER     |         CI LOOP          |                   DESCRIPTION                   |             TESTCASES              |
+---------------------+---------------+--------------------------+-------------------------------------------------+------------------------------------+
|     healthcheck     |       0       |     (daily)|(weekly)     |     First tier to be executed to verify the     |     connection_check api_check     |
|                     |               |                          |           basic operations in the VIM.          |         snaps_health_check         |
+---------------------+---------------+--------------------------+-------------------------------------------------+------------------------------------+

To run all the cases of the tier, type:

# functest tier run healthcheck

Testcase¶

Testcases can be listed, shown and run though the CLI:

# functest testcase list
 connection_check
 api_check
 snaps_health_check
# functest testcase show api_check
+-------------------+--------------------------------------------------+------------------+---------------------------+
|     TEST CASE     |                   DESCRIPTION                    |     CRITERIA     |         DEPENDENCY        |
+-------------------+--------------------------------------------------+------------------+---------------------------+
|     api_check     |     This test case verifies the retrieval of     |       100        |     ^((?!netvirt).)*$     |
|                   |       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.                     |                  |                           |
+-------------------+--------------------------------------------------+------------------+---------------------------+
# functest testcase run connection_check
...
# functest run all

You can also type run_tests -t all to run all the tests.

Note the list of test cases depend on the installer and the scenario.

Reporting results to the test Database¶

In OPNFV CI we collect all the results from CI. A test APi shall be available as well as a test database [17].

Functest internal API¶

An internal API has been introduced in Euphrates. The goal is to trigger Functest operations through an API in addition of the CLI. This could be considered as a first step towards a pseudo micro services approach where the different test projects could expose and consume APIs to the other test projects.

In Euphrates the main method of the APIs are:

Show credentials

Update openrc file

Show environment

Update hosts info for domain name

Prepare environment

List all testcases

Show a testcase

Run a testcase

List all tiers

Show a tier

List all testcases within given tier

Get the result of the specified task

Get the log of the specified task

See [16] to get examples on how to use the API.

Test results¶

Manual testing¶

In manual mode test results are displayed in the console and result files are put in /home/opnfv/functest/results.

If you want additional logs, you may configure the logging.ini under /usr/lib/python2.7/site-packages/functest/ci.

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:

+-------------------------+----------------------------------------------------------+
|         ENV VAR         |                          VALUE                           |
+-------------------------+----------------------------------------------------------+
|      INSTALLER_TYPE     |                          daisy                           |
|     DEPLOY_SCENARIO     |                  os-nosdn-nofeature-ha                   |
|        BUILD_TAG        |     jenkins-functest-daisy-baremetal-daily-master-67     |
|         CI_LOOP         |                          daily                           |
+-------------------------+----------------------------------------------------------+

+------------------------------+------------------+---------------------+------------------+----------------+
|          TEST CASE           |     PROJECT      |         TIER        |     DURATION     |     RESULT     |
+------------------------------+------------------+---------------------+------------------+----------------+
|       connection_check       |     functest     |     healthcheck     |      00:08       |      PASS      |
|          api_check           |     functest     |     healthcheck     |      04:22       |      PASS      |
|      snaps_health_check      |     functest     |     healthcheck     |      00:35       |      PASS      |
|          vping_ssh           |     functest     |        smoke        |      00:54       |      PASS      |
|        vping_userdata        |     functest     |        smoke        |      00:27       |      PASS      |
|     tempest_smoke_serial     |     functest     |        smoke        |      19:39       |      FAIL      |
|         rally_sanity         |     functest     |        smoke        |      15:16       |      PASS      |
|       refstack_defcore       |     functest     |        smoke        |      15:55       |      PASS      |
|         snaps_smoke          |     functest     |        smoke        |      26:45       |      FAIL      |
|           cloudify_ims       |     functest     |         vnf         |      23:56       |      PASS      |
|        orchestra_openims     |     orchestra    |         vnf         |      15:07       |      PASS      |
|     orchestra_clearwaterims  |     orchestra    |         vnf         |      19:10       |      PASS      |
|           vyos_vrouter       |     functest     |         vnf         |      00:00       |      SKIP      |
+------------------------------+------------------+---------------------+------------------+----------------+

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

Test reporting¶

An automatic reporting page has been created in order to provide a consistent view of the Functest tests on the different scenarios.

In this page, each scenario is evaluated according to test criteria.

The results are collected from the centralized database every day and, per scenario. A score is calculated based on the results from the last 10 days. This score is the addition of single test scores. Each test case has a success criteria reflected in the criteria field from the results.

As an illustration, let’s consider the scenario os-odl_l2-nofeature-ha scenario, the scenario scoring is the addition of the scores of all the runnable tests from the categories (tiers, healthcheck, smoke and features) corresponding to this scenario.

Test Apex Compass Fuel Joid

vPing_ssh X X X X

vPing_userdata X X X X

tempest_smoke_serial X X X X

rally_sanity X X X X

odl X X X X

promise X X

doctor X X

security_scan X

parser X

copper X X

src: os-odl_l2-nofeature-ha Colorado (see release note for the last matrix version)

All the testcases (X) listed in the table are runnable on os-odl_l2-nofeature scenarios. Please note that other test cases (e.g. sfc_odl, bgpvpn) need ODL configuration addons and, as a consequence, specific scenario. There are not considered as runnable on the generic odl_l2 scenario.

If no result is available or if all the results are failed, the test case get 0 point. If it was successful at least once but not anymore during the 4 runs, the case get 1 point (it worked once). If at least 3 of the last 4 runs were successful, the case get 2 points. If the last 4 runs of the test are successful, the test get 3 points.

In the example above, the target score for fuel/os-odl_l2-nofeature-ha is 3 x 8 = 24 points and for compass it is 3 x 5 = 15 points .

The scenario is validated per installer when we got 3 points for all individual test cases (e.g 24/24 for fuel, 15/15 for compass).

Please note that complex or long duration tests are not considered yet for the scoring. In fact the success criteria are not always easy to define and may require specific hardware configuration.

Please also note that all the test cases have the same “weight” for the score calculation whatever the complexity of the test case. Concretely a vping has the same weith than the 200 tempst tests. Moreover some installers support more features than others. The more cases your scenario is dealing with, the most difficult to rich a good scoring.

Therefore the scoring provides 3 types of indicators:

the richness of the scenario: if the target scoring is high, it means that the scenario includes lots of features

the maturity: if the percentage (scoring/target scoring * 100) is high, it means that all the tests are PASS

the stability: as the number of iteration is included in the calculation, the pecentage can be high only if the scenario is run regularly (at least more than 4 iterations over the last 10 days in CI)

In any case, the scoring is used to give feedback to the other projects and does not represent an absolute value of the scenario.

See reporting page for details. For the status, click on the version, Functest then the Status menu.

Functest reporting portal Fuel status page

Troubleshooting¶

This section gives some guidelines about how to troubleshoot the test cases owned by Functest.

IMPORTANT: As in the previous section, the steps defined below must be executed inside the Functest Docker container and after sourcing the OpenStack credentials:

. $creds

or:

source /home/opnfv/functest/conf/openstack.creds

VIM¶

This section covers the test cases related to the VIM (healthcheck, vping_ssh, vping_userdata, tempest_smoke_serial, tempest_full_parallel, rally_sanity, rally_full).

vPing common¶

For both vPing test cases (vPing_ssh, and vPing_userdata), the first steps are similar:

Create Glance image

Create Network

Create Security Group

Create Instances

After these actions, the test cases differ and will be explained in their respective section.

These test cases can be run inside the container, using new Functest CLI as follows:

$ functest testcase run vping_ssh
$ functest testcase run vping_userdata

The Functest CLI is designed to route a call to the corresponding internal python scripts, located in paths /usr/lib/python2.7/site-packages/functest/opnfv_tests/openstack/vping/vping_ssh.py and /usr/lib/python2.7/site-packages/functest/opnfv_tests/openstack/vping/vping_userdata.py

Notes:

There is one difference, between the Functest CLI based test case execution compared to the earlier used Bash shell script, which is relevant to point out in troubleshooting scenarios:

The Functest CLI does not yet support the option to suppress clean-up of the generated OpenStack resources, following the execution of a test case.

Explanation: After finishing the test execution, the corresponding script will remove, by default, all created resources in OpenStack (image, instances, network and security group). When troubleshooting, it is advisable sometimes to keep those resources in case the test fails and a manual testing is needed.

It is actually still possible to invoke test execution, with suppression of OpenStack resource cleanup, however this requires invocation of a specific Python script: ‘run_tests’. The OPNFV Functest Developer Guide provides guidance on the use of that Python script in such troubleshooting cases.

Some of the common errors that can appear in this test case are:

vPing_ssh- ERROR - There has been a problem when creating the neutron network....

This means that there has been some problems with Neutron, even before creating the instances. Try to create manually a Neutron network and a Subnet to see if that works. The debug messages will also help to see when it failed (subnet and router creation). Example of Neutron commands (using 10.6.0.0/24 range for example):

neutron net-create net-test
neutron subnet-create --name subnet-test --allocation-pool start=10.6.0.2,end=10.6.0.100 \
--gateway 10.6.0.254 net-test 10.6.0.0/24
neutron router-create test_router
neutron router-interface-add <ROUTER_ID> test_subnet
neutron router-gateway-set <ROUTER_ID> <EXT_NET_NAME>

Another related error can occur while creating the Security Groups for the instances:

vPing_ssh- ERROR - Failed to create the security group...

In this case, proceed to create it manually. These are some hints:

neutron security-group-create sg-test
neutron security-group-rule-create sg-test --direction ingress --protocol icmp \
--remote-ip-prefix 0.0.0.0/0
neutron security-group-rule-create sg-test --direction ingress --ethertype IPv4 \
--protocol tcp --port-range-min 80 --port-range-max 80 --remote-ip-prefix 0.0.0.0/0
neutron security-group-rule-create sg-test --direction egress --ethertype IPv4 \
--protocol tcp --port-range-min 80 --port-range-max 80 --remote-ip-prefix 0.0.0.0/0

The next step is to create the instances. The image used is located in /home/opnfv/functest/data/cirros-0.3.5-x86_64-disk.img and a Glance image is created with the name functest-vping. If booting the instances fails (i.e. the status is not ACTIVE), you can check why it failed by doing:

nova list
nova show <INSTANCE_ID>

It might show some messages about the booting failure. To try that manually:

nova boot --flavor m1.small --image functest-vping --nic net-id=<NET_ID> nova-test

This will spawn a VM using the network created previously manually. In all the OPNFV tested scenarios from CI, it never has been a problem with the previous actions. Further possible problems are explained in the following sections.

vPing_SSH¶

This test case creates a floating IP on the external network and assigns it to the second instance opnfv-vping-2. The purpose of this is to establish a SSH connection to that instance and SCP a script that will ping the first instance. This script is located in the repository under /usr/lib/python2.7/site-packages/functest/opnfv_tests/openstack/vping/ping.sh and takes an IP as a parameter. When the SCP is completed, the test will do a SSH call to that script inside the second instance. Some problems can happen here:

vPing_ssh- ERROR - Cannot establish connection to IP xxx.xxx.xxx.xxx. Aborting

If this is displayed, stop the test or wait for it to finish, if you have used the special method of test invocation with specific supression of OpenStack resource clean-up, as explained earler. It means that the Container can not reach the Public/External IP assigned to the instance opnfv-vping-2. There are many possible reasons, and they really depend on the chosen scenario. For most of the ODL-L3 and ONOS scenarios this has been noticed and it is a known limitation.

First, make sure that the instance opnfv-vping-2 succeeded to get an IP from the DHCP agent. It can be checked by doing:

nova console-log opnfv-vping-2

If the message Sending discover and No lease, failing is shown, it probably means that the Neutron dhcp-agent failed to assign an IP or even that it was not responding. At this point it does not make sense to try to ping the floating IP.

If the instance got an IP properly, try to ping manually the VM from the container:

nova list
<grab the public IP>
ping <public IP>

If the ping does not return anything, try to ping from the Host where the Docker container is running. If that solves the problem, check the iptable rules because there might be some rules rejecting ICMP or TCP traffic coming/going from/to the container.

At this point, if the ping does not work either, try to reproduce the test manually with the steps described above in the vPing common section with the addition:

neutron floatingip-create <EXT_NET_NAME>
nova floating-ip-associate nova-test <FLOATING_IP>

Further troubleshooting is out of scope of this document, as it might be due to problems with the SDN controller. Contact the installer team members or send an email to the corresponding OPNFV mailing list for more information.

vPing_userdata¶

This test case does not create any floating IP neither establishes an SSH connection. Instead, it uses nova-metadata service when creating an instance to pass the same script as before (ping.sh) but as 1-line text. This script will be executed automatically when the second instance opnfv-vping-2 is booted.

The only known problem here for this test to fail is mainly the lack of support of cloud-init (nova-metadata service). Check the console of the instance:

nova console-log opnfv-vping-2

If this text or similar is shown:

checking http://169.254.169.254/2009-04-04/instance-id
failed 1/20: up 1.13. request failed
failed 2/20: up 13.18. request failed
failed 3/20: up 25.20. request failed
failed 4/20: up 37.23. request failed
failed 5/20: up 49.25. request failed
failed 6/20: up 61.27. request failed
failed 7/20: up 73.29. request failed
failed 8/20: up 85.32. request failed
failed 9/20: up 97.34. request failed
failed 10/20: up 109.36. request failed
failed 11/20: up 121.38. request failed
failed 12/20: up 133.40. request failed
failed 13/20: up 145.43. request failed
failed 14/20: up 157.45. request failed
failed 15/20: up 169.48. request failed
failed 16/20: up 181.50. request failed
failed 17/20: up 193.52. request failed
failed 18/20: up 205.54. request failed
failed 19/20: up 217.56. request failed
failed 20/20: up 229.58. request failed
failed to read iid from metadata. tried 20

it means that the instance failed to read from the metadata service. Contact the Functest or installer teams for more information.

Tempest¶

In the upstream OpenStack CI all the Tempest test cases are supposed to pass. If some test cases fail in an OPNFV deployment, the reason is very probably one of the following

Error	Details
Resources required for test case execution are missing	Such resources could be e.g. an external network and access to the management subnet (adminURL) from the Functest docker container.
OpenStack components or services are missing or not configured properly	Check running services in the controller and compute nodes (e.g. with “systemctl” or “service” commands). Configuration parameters can be verified from the related .conf files located under ‘/etc/<component>’ directories.
Some resources required for execution test cases are missing	The tempest.conf file, automatically generated by Rally in Functest, does not contain all the needed parameters or some parameters are not set properly. The tempest.conf file is located in directory ‘root/.rally/verification/verifier-<UUID> /for-deployment-<UUID>’ in the Functest Docker container. Use the “rally deployment list” command in order to check the UUID the UUID of the current deployment.

When some Tempest test case fails, captured traceback and possibly also the related REST API requests/responses are output to the console. More detailed debug information can be found from tempest.log file stored into related Rally deployment folder.

Functest offers a possibility to test a customized list of Tempest test cases. To enable that, add a new entry in docker/components/testcases.yaml on the “components” container with the following content:

-
    case_name: tempest_custom
    project_name: functest
    criteria: 100
    blocking: false
    description: >-
        The test case allows running a customized list of tempest
        test cases
    dependencies:
        installer: ''
        scenario: ''
    run:
        module: 'functest.opnfv_tests.openstack.tempest.tempest'
        class: 'TempestCustom'

Also, a list of the Tempest test cases must be provided to the container or modify the existing one in /usr/lib/python2.7/site-packages/functest/opnfv_tests/openstack/tempest/custom_tests/test_list.txt

Example of custom list of tests ‘my-custom-tempest-tests.txt’:

tempest.scenario.test_server_basic_ops.TestServerBasicOps.test_server_basic_ops[compute,id-7fff3fb3-91d8-4fd0-bd7d-0204f1f180ba,network,smoke]
tempest.scenario.test_network_basic_ops.TestNetworkBasicOps.test_network_basic_ops[compute,id-f323b3ba-82f8-4db7-8ea6-6a895869ec49,network,smoke]

This is an example of running a customized list of Tempest tests in Functest:

sudo docker run --env-file env \
    -v $(pwd)/openstack.creds:/home/opnfv/functest/conf/openstack.creds \
    -v $(pwd)/images:/home/opnfv/functest/images \
    -v $(pwd)/my-custom-testcases.yaml:/usr/lib/python2.7/site-packages/functest/ci/testcases.yaml \
    -v $(pwd)/my-custom-tempest-tests.txt:/usr/lib/python2.7/site-packages/functest/opnfv_tests/openstack/tempest/custom_tests/test_list.txt \
    opnfv/functest-components /bin/bash -c "prepare_env start && run_tests -t tempest_custom"

Rally¶

The same error causes which were mentioned above for Tempest test cases, may also lead to errors in Rally as well.

Possible scenarios are:

authenticate
glance
cinder
heat
keystone
neutron
nova
ceilometer
quotas
vm

To know more about what those scenarios are doing, they are defined in directory: /usr/lib/python2.7/site-packages/functest/opnfv_tests/openstack/rally/scenario For more info about Rally scenario definition please refer to the Rally official documentation. [3]

To check any possible problems with Rally, the logs are stored under /home/opnfv/functest/results/rally/ in the Functest Docker container.

Controllers¶

Opendaylight¶

If the Basic Restconf test suite fails, check that the ODL controller is reachable and its Restconf module has been installed.

If the Neutron Reachability test fails, verify that the modules implementing Neutron requirements have been properly installed.

If any of the other test cases fails, check that Neutron and ODL have been correctly configured to work together. Check Neutron configuration files, accounts, IP addresses etc.).

Features¶

Please refer to the dedicated feature user guides for details.

VNF¶

cloudify_ims¶

vIMS deployment may fail for several reasons, the most frequent ones are described in the following table:

Error	Comments
Keystone admin API not reachable	Impossible to create vIMS user and tenant
Impossible to retrieve admin role id	Impossible to create vIMS user and tenant
Error when uploading image from OpenStack to glance	impossible to deploy VNF
Cinder quota cannot be updated	Default quotas not sufficient, they are adapted in the script
Impossible to create a volume	VNF cannot be deployed
SSH connection issue between the Test Docker container and the VM	if vPing test fails, vIMS test will fail...
No Internet access from the VM	the VMs of the VNF must have an external access to Internet
No access to OpenStack API from the VM	Orchestrator can be installed but the vIMS VNF installation fails

Please note that this test case requires resources (8 VM (2Go) + 1 VM (4Go)), it is there fore not recommended to run it on a light configuration.

References¶

[1]: Functest configuration guide

[2]: OpenStack Tempest documentation

[3]: Rally documentation

[4]: Functest in depth (Danube)

[5]: Clearwater vIMS blueprint

[6]: NIST web site

[7]: OpenSCAP web site

[8]: Refstack client

[9]: Defcore

[10]: OpenStack interoperability procedure

[11]: Robot Framework web site

[12]: Functest User guide

[13]: SNAPS wiki

[14]: vRouter

[15]: Testing OpenStack Tempest part 1

[16]: Running Functest through internal REST API

[17]: OPNFV Test API

OPNFV main site: OPNFV official web site

Functest page: Functest wiki page

IRC support chan: #opnfv-functest

Test	Apex	Compass	Fuel	Joid
vPing_ssh	X	X	X	X
vPing_userdata	X	X	X	X
tempest_smoke_serial	X	X	X	X
rally_sanity	X	X	X	X
odl	X	X	X	X
promise			X	X
doctor	X		X
security_scan	X
parser			X
copper	X			X