OPNFV FUNCTEST developer guide¶

Introduction¶

Functest is a project dealing with functional testing. Functest produces its own internal test cases but can also be considered as a framework to support feature project testing. Functest developed a test API and defined a test collection framework that can be used by any OPNFV project.

Therefore there are many ways to contribute to Functest. You can:

Develop new internal test cases

Integrate the tests from your feature project

Develop the framework to ease the integration of external test cases

Develop the API / Test collection framework

Develop dashboards or automatic reporting portals

This document describes how, as a developer, you may interact with the Functest project. The first section details the main working areas of the project. The Second part is a list of “How to” to help you to join the Functest family whatever your field of interest is.

Functest developer areas¶

Functest High level architecture¶

Functest is project delivering a test container dedicated to OPNFV. It includes the tools, the scripts and the test scenarios.

Functest can be described as follow:

+----------------------+
|                      |
|   +--------------+   |                  +-------------------+
|   |              |   |    Public        |                   |
|   | Tools        |   +------------------+      OPNFV        |
|   | Scripts      |   |                  | System Under Test |
|   | Scenarios    |   +------------------+                   |
|   |              |   |    Management    |                   |
|   +--------------+   |                  +-------------------+
|                      |
|    Functest Docker   |
|                      |
+----------------------+

Functest internal test cases¶

The internal test cases in Colorado are:

healthcheck

vping_ssh

vping_userdata

odl

tempest_smoke_serial

rally_sanity

tempest_full_parallel

rally_full

vims

By internal, we mean that this particular test cases have been developped and/or integrated by functest contributors and the associated code is hosted in the Functest repository. An internal case can be fully developped or a simple integration of upstream suites (e.g. Tempest/Rally developped in OpenStack are just integrated in Functest). The structure of this repository is detailed in [1]. The main internal test cases are in the testcases subfolder of the repository, the internal test cases are:

Controllers: odl, onos, ocl

OpenStack: healthcheck, vping_ssh, vping_userdata, tempest_*, rally_*

VNF: vims

If you want to create a new test case you will have to create a new folder under the testcases directory.

Functest external test cases¶

The external test cases are inherited from other OPNFV projects, especially the feature projects.

The external test cases are:

promise

doctor

onos

bgpvpn

copper

moon

security_scan

sfc-odl

sfc-onos

parser

domino

multisite

Note that security_scan has been bootstraped in Functest but is considered as an external test case as it gets its own repository.

The code to run these test cases may be directly in the repository of the project. We have also a features sub directory under testcases directory that may be used (it can be usefull if you want to reuse Functest library).

Functest framework¶

Functest can be considered as a framework. Functest is release as a docker file, including tools, scripts and a CLI to prepare the environement and run tests. It simplifies the integration of external test suites in CI pipeline and provide commodity tools to collect and display results.

Since Colorado, test categories also known as tiers have been created to group similar tests, provide consistant sub-lists and at the end optimize test duration for CI (see How To section).

see http://artifacts.opnfv.org/functest/docs/userguide/index.html for details.

Test collection framework¶

The OPNFV testing group created a test collection database to collect the test results from CI:

http://testresults.opnfv.org/test/swagger/spec.html

Authentication: opnfv/api@opnfv

Any test project running on any lab integrated in CI can push the results to this database. This database can be used to see the evolution of the tests and compare the results versus the installers, the scenarios or the labs.

Overall Architecture¶

The Test result management can be summarized as follows:

+-------------+    +-------------+    +-------------+
|             |    |             |    |             |
|   Test      |    |   Test      |    |   Test      |
| Project #1  |    | Project #2  |    | Project #N  |
|             |    |             |    |             |
+-------------+    +-------------+    +-------------+
         |               |               |
         V               V               V
     +-----------------------------------------+
     |                                         |
     |         Test Rest API front end         |
     |  http://testresults.opnfv.org/test      |
     |                                         |
     +-----------------------------------------+
         A                |
         |                V
         |     +-------------------------+
         |     |                         |
         |     |    Test Results DB      |
         |     |         Mongo DB        |
         |     |                         |
         |     +-------------------------+
         |
         |
   +----------------------+
   |                      |
   |    test Dashboard    |
   |                      |
   +----------------------+

Test API description¶

The Test API is used to declare pods, projects, test cases and test results. Pods are the pods used to run the tests. The results pushed in the database are related to pods, projects and cases. If you try to push results of test done on non referenced pod, the API will return an error message.

An additional method dashboard has been added to post-process the raw results in release Brahmaputra (deprecated in Colorado).

The data model is very basic, 4 objects are created:

Pods

Projects

Testcases

Results

Pods:

{
  "id": <ID>,
  "details": <URL description of the POD>,
  "creation_date": "YYYY-MM-DD HH:MM:SS",
  "name": <The POD Name>,
  "mode": <metal or virtual>,
  "role": <ci-pod or community-pod or single-node>
},

Projects:

{
  "id": <ID>,
  "name": <Name of the Project>,
  "creation_date": "YYYY-MM-DD HH:MM:SS",
  "description": <Short description>
},

Testcases:

{
  "id": <ID>,
  "name":<Name of the test case>,
  "project_name":<Name of belonged project>,
  "creation_date": "YYYY-MM-DD HH:MM:SS",
  "description": <short description>,
  "url":<URL for longer description>
},

Results:

{
  "_id": <ID>,
  "case_name": <Reference to the test case>,
  "project_name": <Reference to project>,
  "pod_name": <Reference to POD where the test was executed>,
  "installer": <Installer Apex or Compass or Fuel or Joid>,
  "version": <master or Colorado or Brahmaputra>,
  "start_date": "YYYY-MM-DD HH:MM:SS",
  "stop_date": "YYYY-MM-DD HH:MM:SS",
  "build_tag": <such as "jenkins-functest-fuel-baremetal-daily-master-108">,
  "scenario": <Scenario on which the test was executed>,
  "criteria": <PASS or FAILED>,
  "trust_indicator": {
                      "current": 0,
                      "histories": []
                     }
}

The API can described as follows. For detailed information, please go to

http://testresults.opnfv.org/test/swagger/spec.html

Authentication: opnfv/api@opnfv

Please notes that POST/DELETE/PUT operations for test or study purpose via swagger website is not allowed, because it will change the real data in the database.

Version:

Method Path Description

GET /versions Get all supported API versions

Pods:

Method Path Description

GET /api/v1/pods Get the list of declared Labs (PODs)

POST /api/v1/pods Declare a new POD Content-Type: application/json { “name”: “pod_foo”, “mode”: “metal”, “role”: “ci-pod”, “details”: “it is a ci pod” }

GET /api/v1/pods/{pod_name} Get a declared POD

Projects:

Method Path Description

GET /api/v1/projects Get the list of declared projects

POST /api/v1/projects Declare a new test project Content-Type: application/json { “name”: “project_foo”, “description”: “whatever you want” }

DELETE /api/v1/projects/{project} Delete a test project

GET /api/v1/projects/{project} Get details on a {project}

PUT /api/v1/projects/{project}
Update a test project

Content-Type: application/json { <the field(s) you want to modify> }

Testcases:

Method Path Description

GET /api/v1/projects/{project}/ cases Get the list of testcases of {project}

POST /api/v1/projects/{project}/ cases Add a new test case to {project} Content-Type: application/json { “name”: “case_foo”, “description”: “whatever you want” “url”: “whatever you want” }

DELETE /api/v1/projects/{project}/ cases/{case} Delete a test case

GET /api/v1/projects/{project}/ cases/{case} Get a declared test case

PUT /api/v1/projects/{project}? cases/{case}
Modify a test case of {project}

Content-Type: application/json { <the field(s) you want to modify> }

Results:

Method Path Description

GET /api/v1/results Get all the test results

POST /api/v1/results Add a new test results Content-Type: application/json { “project_name”: “project_foo”, “scenario”: “odl-l2”, “stop_date”: “2016-05-28T14:42:58.384Z”, “trust_indicator”: 0.5, “case_name”: “vPing”, “build_tag”: “”, “version”: “Colorado”, “pod_name”: “pod_foo”, “criteria”: “PASS”, “installer”: “fuel”, “start_date”: “2016-05-28T14:41:58.384Z”, “details”: <your results> }

GET /api/v1/results? case={case} Get the test results of {case}

GET /api/v1/results? build_tag={tag} Get the test results of build_tag {tag}.

GET /api/v1/results? last={N} Get last {N} records of test results

GET /api/v1/results? scenario={scenario} Get the test results of scenario {scenario}.

GET /api/v1/results? trust_indicator={ind} Get the test results of trust_indicator {ind}.

GET /api/v1/results? period={period} Get the test results of last days {period}.

GET /api/v1/results? project={project} Get the test results of {project}

GET /api/v1/results? version={version} Get the test results of version {version}.

GET /api/v1/results? criteria={criteria} Get the test results of criteria {criteria}.

GET /api/v1/results? pod={pod} get the results on pod {pod}

GET /api/v1/results? installer={inst} Get the test results of installer {inst}

GET /api/v1/results? <query conditions> Get the results according to combined query conditions supported above

GET /api/v1/results/{result_id} Get the test result by result_id

Dashboard:

Method Path Description

GET /dashboard/v1/results? &project={project} &case={case} Get all the dashboard ready results of {case} of the project {project}

GET /dashboard/v1/results? &project={project} &case={case} &version={version} Get all the dashboard ready results of {case} of the project {project} version {version}

GET /dashboard/v1/results? &project={project} &case={case} &period={days} Get all the dashboard ready results of {case} of the project {project} since {days} days

GET /dashboard/v1/results? &project={project} &case={case} &installer={installer} Get all the dashboard ready results of {case} of the project {project} installed by {installer}

GET /dashboard/v1/results? &project={project} &case={case} &pod={pod} Get all the dashboard ready results of {case} of the project {project} on POD {pod}

GET /dashboard/v1/results? &project={project} &case={case} &<query conditions> Get all the dashboard ready results of {case} of the project {project} and combined by other query conditions supported above.

GET /dashboard/v1/projects? Get all the dashboard ready projects

The code of the API is hosted in the releng repository [6]. The test API has been dockerized and may be installed locally in your lab. See [15] for details.

Dashboard¶

Dashboard is used to provide a consistant view of the results collected in CI. The results with dashboard method are post-processed from raw results. Please note that dashboard results are not stored. Only raw results are stored.

Release Brahmaputra¶

Dashboard url: http://testresults.opnfv.org/dashboard/

Release Colorado¶

Since Colorado, it was decided to adopt ELK framework. Mongo DB results are extracted to feed Elasticsearch database ([7]).

Dashboard url: http://testresults.opnfv.org/kibana_dashboards/

Credentials for a guest account: opnfvuser/kibana

A script has been developped to build elasticsearch data set. This script can be found in [16].

Automatic reporting¶

An automatic reporting page has been created in order to provide a consistant view of the scenarios. In this page each scenario is evaluated according to test criteria. The code for the automatic reporting is available at [8].

The results are collected from the centralized database every day and, per scenario. A score is calculated based on the results from the last 50 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.

Considering an instance of a scenario os-odl_l2-nofeature-ha, the scoring is the addition of the scores of all the runnable tests from the categories (tiers healthcheck, smoke, controller and feature) 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

moon X

copper X X

All the testcases listed in the table are runnable on os-odl_l2-nofeature scenarios. If no result is available or if all the results are failed, the test case get 0 point. If it was succesfull 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 3x6 = 18 points.

The scenario is validated per installer when we got 3 points for all individual test cases (e.g 18/18). Please note that complex or long duration tests are not considered for the scoring. The success criteria are not always easy to define and may require specific hardware configuration. These results however provide a good level of trust on the scenario.

A web page is automatically generated every day to display the status. This page can be found at [9]. For the status, click on Status menu, you may also get feedback for vims and tempest_smoke_serial test cases.

Any validated scenario is stored in a local file on the web server. In fact as we are using a sliding windows to get results, it may happen that a successful scenarios is no more run (because considered as stable) and then the number of iterations (4 needed) would not be sufficient to get the green status.

Please note that other test cases e.g. sfc_odl, bgpvpn, moon) need also ODL configuration addons and as a consequence specific scenario. There are not considered as runnable on the generic odl_l2 scenario.

How TOs¶

How Functest works?¶

The installation and configuration of the Functest docker image is described in [1].

The procedure to start tests is described in [2]

How can I contribute to Functest?¶

If you are already a contributor of any OPNFV project, you can contribute to functest. If you are totally new to OPNFV, you must first create your Linux Foundation account, then contact us in order to declare you in the repository database.

We distinguish 2 levels of contributors:

the standard contributor can push patch and vote +1/0/-1 on any Functest patch

The commitor can vote -2/-1/0/+1/+2 and merge

Functest commitors are promoted by the Functest contributors.

Where can I find some help to start?¶

This guide is made for you. You can also have a look at the project wiki page [10]. There are references on documentation, video tutorials, tips...

You can also directly contact us by mail with [Functest] prefix in the title at opnfv-tech-discuss@lists.opnfv.org or on the IRC chan #opnfv-functest.

What kind of testing do you do in Functest?¶

Functest is focusing on Functional testing. The results must be PASS or FAIL. We do not deal with performance and/or qualification tests. We consider OPNFV as a black box and execute our tests from the jumphost according to Pharos reference technical architecture.

Upstream test suites are integrated (Rally/Tempest/ODL/ONOS,...). If needed Functest may bootstrap temporarily testing activities if they are identified but not covered yet by an existing testing project (e.g security_scan before the creation of the security repository)

How test constraints are defined?¶

Test constraints are defined according to 2 paramaters:

The scenario (DEPLOY_SCENARIO env variable)

The installer (INSTALLER_TYPE env variable)

A scenario is a formal description of the system under test. The rules to define a scenario are described in [4]

These 2 constraints are considered to determinate if the test is runnable or not (e.g. no need to run onos suite on odl scenario).

In the test declaration for CI, the test owner shall indicate these 2 constraints. The file testcases.yaml [5] must be patched in git to include new test cases. A more elaborated system based on template is planned for next releases

For each dependency, it is possible to define a regex:

name: promise
criteria: 'success_rate == 100%'
description: >-
    Test suite from Promise project.
dependencies:
    installer: '(fuel)|(joid)'
    scenario: ''

In the example above, it means that promise test will be runnable only with joid or fuel installers on any scenario.

The vims criteria means any installer and exclude onos and odl with bgpvpn scenarios:

name: vims
criteria: 'status == "PASS"'
description: >-
    This test case deploys an OpenSource vIMS solution from Clearwater
    using the Cloudify orchestrator. It also runs some signaling traffic.
dependencies:
    installer: ''
    scenario: '(ocl)|(nosdn)|^(os-odl)((?!bgpvpn).)*$'

How to write and check constaint regex?¶

Regex are standard regex. You can have a look at [11]

You can also easily test your regex via an online regex checker such as [12]. Put your scenario in the TEST STRING window (e.g. os-odl_l3-ovs-ha), put your regex in the REGULAR EXPRESSION window, then you can test your rule .

How to know which test I can run?¶

You can use the API [13]. The static declaration is in git [5]

If you are in a Functest docker container (assuming that the environement has been prepared): just use the CLI.

You can get the list per Test cases or by Tier:

# functest testcase list
healthcheck
vping_ssh
vping_userdata
tempest_smoke_serial
rally_sanity
odl
doctor
security_scan
tempest_full_parallel
rally_full
vims
# functest tier list
- 0. healthcheck:
['healthcheck']
- 1. smoke:
['vping_ssh', 'vping_userdata', 'tempest_smoke_serial', 'rally_sanity']
- 2. sdn_suites:
['odl']
- 3. features:
['doctor', 'security_scan']
- 4. openstack:
['tempest_full_parallel', 'rally_full']
- 5. vnf:
['vims']

How to manually start Functest tests?¶

Assuming that you are connected on the jumphost and that the system is “Pharos compliant”, i.e the technical architecture is compatible with the one defined in the Pharos project:

# docker pull opnfv/functest:latest
# envs="-e INSTALLER_TYPE=fuel -e INSTALLER_IP=10.20.0.2 -e DEPLOY_SCENARIO=os-odl_l2-nofeature-ha -e CI_DEBUG=true"
# sudo docker run --privileged=true -id ${envs} opnfv/functest:latest /bin/bash

Then you must connect to the docker container and source the credentials:

# docker ps (copy the id)
# docker exec -ti <container_id> bash
# source $creds

You must first check if the environment is ready:

# functest env status
Functest environment ready to run tests.

If not ready, prepare the env by launching:

# functest env prepare
Functest environment ready to run tests.

Once the Functest env is ready, you can use the CLI to start tests.

You can run test cases per test case or per tier:: # functest testcase run <case name> or # functest tier run <tier name>

e.g:

# functest testcase run tempest_smoke_serial
# functest tier run features

If you want to run all the tests you can type:

# functest testcase run all

If you want to run all the tiers (same at the end that running all the test cases) you can type:

# functest tier run all

How to declare my tests in Functest?¶

If you want to add new internal test cases, you can submit patch under the testcases directory of Functest repository.

For feature test integration, the code can be kept into your own repository. The Functest files to be modified are:

functest/docker/Dockerfile: get your code in Functest container

functest/ci/testcases.yaml: reference your test and its associated constraints

functest/ci/exec_test.sh: run your test from CI and CLI

Dockerfile¶

This file lists the repositories (internal or external) to be cloned in the Functest container. You can also add external packages:

RUN git clone https://gerrit.opnfv.org/gerrit/<your project> ${repos_dir}/<your project>

testcases.yaml¶

All the test cases that must be run from CI / CLI must be declared in ci/testcases.yaml.

This file is used to get the constraints related to the test:

name: <my_super_test_case>
criteria: <not used yet in Colorado, could be > 'PASS', 'rate > 90%'
description: >-
    <the description of your super test suite>
dependencies:
    installer: regex related to installer e.g. 'fuel', '(apex)||(joid)'
    scenario: regex related to the scenario e.g. 'ovs*no-ha'

You must declare your test case in one of the category (tier).

If you are integrating test suites from a feature project, the default category is features.

exec_test.sh¶

This file is used to start your test. It is used in CI but also by the CLI.

You just patch the file in git and add a line:

"<my_super_test_case>")
    python ${FUNCTEST_REPO_DIR}/testcases/features/mycase.py
;;

Note you can use python or bash scripts (or any language assuming that the packages have been properly preinstalled but we recommand python or bash..).

How to select my list of tests for CI?¶

Functest can be run automatically from CI, a jenkins job is usually called after an OPNFV fresh installation. By default we try to run all the possible tests (see [14] called from Functest jenkins job):

cmd="python ${FUNCTEST_REPO_DIR}/ci/run_tests.py -t all ${flags}"

Each case can be configured as daily and/or weekly task. When executing run_tests.py, a check based on the jenkins build tag will be considered to detect whether it is a daily and/or a weekly test.

in your CI you can customize the list of test you want to run by case or by tier, just change the line:

cmd="python ${FUNCTEST_REPO_DIR}/ci/run_tests.py -t <whatever you want> ${flags}"

e.g.:

cmd="python ${FUNCTEST_REPO_DIR}/ci/run_tests.py -t healthcheck,smoke ${flags}"

This command will run all the test cases of the first 2 tiers, i.e. healthcheck, vping_ssh, vping_userdata, tempest_smoke_serial and rally_sanity.

How to push your results into the Test Database¶

The test database is used to collect test results. By default it is enabled only for CI tests from Production CI pods.

The architecture and associated API is described in previous chapter. If you want to push your results from CI, you just have to call the API at the end of your script.

You can also reuse a python function defined in functest_utils.py:

def push_results_to_db(db_url, case_name, logger, pod_name,version, payload):
  """
  POST results to the Result target DB
  """
  url = db_url + "/results"
  installer = get_installer_type(logger)
  params = {"project_name": "functest", "case_name": case_name,
            "pod_name": pod_name, "installer": installer,
            "version": version, "details": payload}

  headers = {'Content-Type': 'application/json'}
  try:
      r = requests.post(url, data=json.dumps(params), headers=headers)
      if logger:
          logger.debug(r)
      return True
  except Exception, e:
      print "Error [push_results_to_db('%s', '%s', '%s', '%s', '%s')]:" \
          % (db_url, case_name, pod_name, version, payload), e
      return False

References¶

[1]: http://artifacts.opnfv.org/functest/docs/configguide/index.html Functest configuration guide

[2]: http://artifacts.opnfv.org/functest/docs/userguide/index.html functest user guide

[3]: https://wiki.opnfv.org/opnfv_test_dashboard Brahmaputra dashboard

[4]: https://wiki.opnfv.org/display/INF/CI+Scenario+Naming

[5]: https://git.opnfv.org/cgit/functest/tree/ci/testcases.yaml

[6]: https://git.opnfv.org/cgit/releng/tree/utils/test/result_collection_api

[7]: https://git.opnfv.org/cgit/releng/tree/utils/test/scripts

[8]: https://git.opnfv.org/cgit/releng/tree/utils/test/reporting/functest

[9]: http://testresults.opnfv.org/reporting/

[10]: https://wiki.opnfv.org/opnfv_functional_testing

[11]: https://docs.python.org/2/howto/regex.html

[12]: https://regex101.com/

[13]: http://testresults.opnfv.org/test/api/v1/projects/functest/cases

[14]: https://git.opnfv.org/cgit/releng/tree/jjb/functest/functest-daily.sh

[15]: https://git.opnfv.org/cgit/releng/tree/utils/test/result_collection_api/README.rst

[16]: https://git.opnfv.org/cgit/releng/tree/utils/test/scripts/mongo_to_elasticsearch.py

OPNFV main site: http://www.opnfv.org

OPNFV functional test page: https://wiki.opnfv.org/opnfv_functional_testing

IRC support chan: #opnfv-functest

OpenRC: http://docs.openstack.org/user-guide/common/cli_set_environment_variables_using_openstack_rc.html

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