1 ******************************
2 OPNFV FUNCTEST developer guide
3 ******************************
14 Functest is a project dealing with functional testing.
15 Functest produces its own internal test cases but can also be considered
16 as a framework to support feature project testing suite integration.
17 Functest developed a test API and defined a Test collection framework
18 that can be used by any OPNFV project.
20 Therefore there are many ways to contribute to Functest. You can:
22 * develop new internal test cases
23 * integrate the tests from your feature project
24 * develop the framework to ease the integration of external test cases
25 * develop the API / Test collection framework
26 * develop dashboards or automatic reporting portals
28 This document describes how, as a developer, you may interact with the
29 Functest project. The first section details the main working areas of
30 the project. The Second part is a list of "How to" to help you to join
31 the Functest family whatever your field of interest is.
34 ========================
35 Functest developer areas
36 ========================
39 Functest High level architecture
40 ================================
42 Functest is project delivering a test container dedicated to OPNFV.
43 It includes the tools, the scripts and the test scenarios.
45 Functest can be described as follow::
47 +----------------------+
49 | +--------------+ | +-------------------+
51 | | Tools | +------------------+ OPNFV |
52 | | Scripts | | | System Under Test |
53 | | Scenarios | +------------------+ |
54 | | | | Management | |
55 | +--------------+ | +-------------------+
59 +----------------------+
61 Functest internal test cases
62 ============================
63 The internal test cases in Colorado are:
68 * tempest_smoke_serial
70 * tempest_full_parallel
74 By internal, we mean that this particular test cases have been
75 developped by functest contributors and the associated code is hosted in
76 the Functest repository.
77 The structure of this repository is detailed in `[1]`_.
78 The main internal test cases are int the testcases subfolder of the
79 repository, the internal test cases are:
81 * Controllers: odl, onos
82 * OpenStack: vping_ssh, vping_userdata, tempest_*, rally_*
85 If you want to create a new test cases you will have to create a new
86 folder under the testcases directory
88 Functest external test cases
89 ============================
90 The external tescases are:
103 Note that security_scan has been bootstraped in Functest but will be
104 considered as an external test cases as soon as it will get its own
107 The code to run these test cases may be directly in the repository of
108 the project. We have also a features sub directory under testcases
109 directory that may be used (it can be usefull if you want to reuse
116 Functest can be considered as a framework.
117 Functest is release a a docker file, including tools, scripts and a CLI
118 to prepare the environement and run tests.
119 It simplifies the integration of external test suite in CI pipeline
120 and provide commodity tools to collect and display results.
122 Since Colorado, test categories also known as tiers have been created to
123 group similar tests, provide consistant sub-lists and at the end optimize
124 test duration for CI (see How To section).
126 see `[2]`_ for details.
131 The OPNFV testing group created a test collection database to collect
132 the test results from CI.
133 Any test project running on any lab integrated in CI can push the
134 results to this database.
135 This database can be used afterwards to see the evolution of the tests
136 and compare the results versus the installers, the scenario or the labs.
138 You can find more information about the dashboard from Testing Dashboard
143 The Test result management can be summarized as follows::
145 +-------------+ +-------------+ +-------------+
147 | Test | | Test | | Test |
148 | Project #1 | | Project #2 | | Project #N |
150 +-------------+ +-------------+ +-------------+
153 +-----------------------------------------+
155 | Test Rest API front end |
156 | http://testresults.opnfv.org/test |
158 +-----------------------------------------+
161 | +-------------------------+
163 | | Test Results DB |
166 | +-------------------------+
169 +----------------------+
173 +----------------------+
177 The Test API is used to declare pods, projects, test cases and test
178 results. An additional method dashboard has been added to post-process
179 the raw results in release Brahmaputra.
181 The data model is very basic, 4 objects are created:
192 "details": <URL description of the POD>,
193 "creation_date": "YYYY-MM-DD HH:MM:SS",
194 "name": <The POD Name>,
195 "mode": <metal or virtual>,
196 "role": <ci-pod or community-pod or single-node>
203 "name": <Name of the Project>,
204 "creation_date": "YYYY-MM-DD HH:MM:SS",
205 "description": <Short description>
212 "name":<Name of the test case>,
213 "project_name":<Name of belonged project>,
214 "creation_date": "YYYY-MM-DD HH:MM:SS",
215 "description": <short description>,
216 "url":<URL for longer description>
223 "case_name": <Reference to the test case>,
224 "project_name": <Reference to project>,
225 "pod_name": <Reference to POD where the test was executed>,
226 "installer": <Installer Apex or Compass or Fuel or Joid>,
227 "version": <master or Colorado or Brahmaputra>,
228 "start_date": "YYYY-MM-DD HH:MM:SS",
229 "stop_date": "YYYY-MM-DD HH:MM:SS",
230 "build_tag": <such as "jenkins-functest-fuel-baremetal-daily-master-108">,
231 "scenario": <Scenario on which the test was executed>,
232 "criteria": <PASS or FAILED>,
233 "trust_indicator": <0~1>
236 The API can described as follows. For detailed information, please go to
237 http://testresults.opnfv.org/test/swagger/spec.html
239 Authentication: opnfv/api@opnfv
241 Please notes that POST/DELETE/PUT operations for test or study purpose via
242 swagger website is not allowed, because it will change the real data in
247 +--------+--------------------------+-----------------------------------------+
248 | Method | Path | Description |
249 +========+==========================+=========================================+
250 | GET | /versions | Get all supported API versions |
251 +--------+--------------------------+-----------------------------------------+
256 +--------+----------------------------+-----------------------------------------+
257 | Method | Path | Description |
258 +========+============================+=========================================+
259 | GET | /api/v1/pods | Get the list of declared Labs (PODs) |
260 +--------+----------------------------+-----------------------------------------+
261 | POST | /api/v1/pods | Declare a new POD |
262 | | | Content-Type: application/json |
264 | | | "name": "pod_foo", |
265 | | | "mode": "metal", |
266 | | | "role": "ci-pod", |
267 | | | "details": "it is a ci pod" |
269 +--------+----------------------------+-----------------------------------------+
270 | GET | /api/v1/pods/{pod_name} | Get a declared POD |
271 +--------+----------------------------+-----------------------------------------+
275 +--------+----------------------------+-----------------------------------------+
276 | Method | Path | Description |
277 +========+============================+=========================================+
278 | GET | /api/v1/projects | Get the list of declared projects |
279 +--------+----------------------------+-----------------------------------------+
280 | POST | /api/v1/projects | Declare a new test project |
281 | | | Content-Type: application/json |
283 | | | "name": "project_foo", |
284 | | | "description": "whatever you want" |
286 +--------+----------------------------+-----------------------------------------+
287 | DELETE | /api/v1/projects/{project} | Delete a test project |
288 +--------+----------------------------+-----------------------------------------+
289 | GET | /api/v1/projects/{project} | Get details on a {project} |
291 +--------+----------------------------+-----------------------------------------+
292 | PUT | /api/v1/projects/{project} | Update a test project |
294 | | | Content-Type: application/json |
296 | | | <the field(s) you want to modify> |
298 +--------+----------------------------+-----------------------------------------+
303 +--------+----------------------------+-----------------------------------------+
304 | Method | Path | Description |
305 +========+============================+=========================================+
306 | GET | /api/v1/projects/{project}/| Get the list of testcases of {project} |
308 +--------+----------------------------+-----------------------------------------+
309 | POST | /api/v1/projects/{project}/| Add a new test case to {project} |
310 | | cases | Content-Type: application/json |
312 | | | "name": "case_foo", |
313 | | | "description": "whatever you want" |
314 | | | "url": "whatever you want" |
316 +--------+----------------------------+-----------------------------------------+
317 | DELETE | /api/v1/projects/{project}/| Delete a test case |
319 +--------+----------------------------+-----------------------------------------+
320 | GET | /api/v1/projects/{project}/| Get a declared test case |
322 +--------+----------------------------+-----------------------------------------+
323 | PUT | /api/v1/projects/{project}?| Modify a test case of {project} |
325 | | | Content-Type: application/json |
327 | | | <the field(s) you want to modify> |
329 +--------+----------------------------+-----------------------------------------+
333 +--------+----------------------------+------------------------------------------+
334 | Method | Path | Description |
335 +========+============================+==========================================+
336 | GET | /api/v1/results | Get all the test results |
337 +--------+----------------------------+------------------------------------------+
338 | POST | /api/v1/results | Add a new test results |
339 | | | Content-Type: application/json |
341 | | | "project_name": "project_foo", |
342 | | | "scenario": "odl-l2", |
343 | | | "stop_date": "2016-05-28T14:42:58.384Z", |
344 | | | "trust_indicator": 0.5, |
345 | | | "case_name": "vPing", |
346 | | | "build_tag": "", |
347 | | | "version": "Colorado", |
348 | | | "pod_name": "pod_foo", |
349 | | | "criteria": "PASS", |
350 | | | "installer": "fuel", |
351 | | | "start_date": "2016-05-28T14:41:58.384Z",|
352 | | | "details": <your results> |
354 +--------+----------------------------+------------------------------------------+
355 | GET | /api/v1/results? | Get the test results of {case} |
357 +--------+----------------------------+------------------------------------------+
358 | GET | /api/v1/results? | Get the test results of build_tag |
359 | | build_tag={tag} | {tag}. |
360 +--------+----------------------------+------------------------------------------+
361 | GET | /api/v1/results? | Get last {N} records of test results |
363 +--------+----------------------------+------------------------------------------+
364 | GET | /api/v1/results? | Get the test results of scenario |
365 | | scenario={scenario} | {scenario}. |
366 +--------+----------------------------+------------------------------------------+
367 | GET | /api/v1/results? | Get the test results of trust_indicator |
368 | | trust_indicator={ind} | {ind}. |
369 +--------+----------------------------+------------------------------------------+
370 | GET | /api/v1/results? | Get the test results of last days |
371 | | period={period} | {period}. |
372 +--------+----------------------------+------------------------------------------+
373 | GET | /api/v1/results? | Get the test results of {project} |
374 | | project={project} | |
375 +--------+----------------------------+------------------------------------------+
376 | GET | /api/v1/results? | Get the test results of version |
377 | | version={version} | {version}. |
378 +--------+----------------------------+------------------------------------------+
379 | GET | /api/v1/results? | Get the test results of criteria |
380 | | criteria={criteria} | {criteria}. |
381 +--------+----------------------------+------------------------------------------+
382 | GET | /api/v1/results? | get the results on pod {pod} |
384 +--------+----------------------------+------------------------------------------+
385 | GET | /api/v1/results? | Get the test results of installer {inst} |
386 | | installer={inst} | |
387 +--------+----------------------------+------------------------------------------+
388 | GET | /api/v1/results? | Get the results according to combined |
389 | | <query conditions> | query conditions supported above |
390 +--------+----------------------------+------------------------------------------+
391 | GET | /api/v1/results/{result_id}| Get the test result by result_id |
392 +--------+----------------------------+------------------------------------------+
397 +--------+----------------------------+-----------------------------------------+
398 | Method | Path | Description |
399 +========+============================+=========================================+
400 | GET |/dashboard/v1/results? | Get all the dashboard ready results of |
401 | |&project={project} | {case} of the project {project} |
403 +--------+----------------------------+-----------------------------------------+
404 | GET |/dashboard/v1/results? | Get all the dashboard ready results of |
405 | |&project={project} | {case} of the project {project} |
406 | |&case={case} | version {version} |
407 | |&version={version} | |
408 +--------+----------------------------+-----------------------------------------+
409 | GET |/dashboard/v1/results? | Get all the dashboard ready results of |
410 | |&project={project} | {case} of the project {project} |
411 | |&case={case} | since {days} days |
412 | |&period={days} | |
413 +--------+----------------------------+-----------------------------------------+
414 | GET |/dashboard/v1/results? | Get all the dashboard ready results of |
415 | |&project={project} | {case} of the project {project} |
416 | |&case={case} | installed by {installer} |
417 | |&installer={installer} | |
418 +--------+----------------------------+-----------------------------------------+
419 | GET |/dashboard/v1/results? | Get all the dashboard ready results of |
420 | |&project={project} | {case} of the project {project} |
421 | |&case={case} | on POD {pod} |
423 +--------+----------------------------+-----------------------------------------+
424 | GET |/dashboard/v1/results? | Get all the dashboard ready results of |
425 | |&project={project} | {case} of the project {project} |
426 | |&case={case} | and combined by other query conditions |
427 | |&<query conditions> | supported above. |
428 +--------+----------------------------+-----------------------------------------+
429 | GET |/dashboard/v1/projects? | Get all the dashboard ready projects |
430 +--------+----------------------------+-----------------------------------------+
432 The code of the API is hosted in the releng repository `[6]`_.
437 Dashboard is used to provide a consistant view of the results collected
439 The results with dashboard method are post-processed from raw results.
440 Please note that dashboard results are not stored. Only raw results are
446 Dashboard url: http://testresults.opnfv.org/dashboard/
450 Since Colorado, it was decided to adopt ELK framework. Mongo DB results
451 are extracted to feed Elasticsearch database (`[7]`_).
453 Dashboard url: http://testresults.opnfv.org/kibana_dashboards/
455 Credentials for a guest account: opnfvuser/kibana
461 OPNFV release is scenario centric. An automatic reporting page has been
462 created in order to provide a consistant view of the scenarios.
463 In this page each scenario is evaluated according to test criteria.
464 The code for the automatic reporting is available at `[8]`_.
466 Every day, we collect the results from the centralized database and, per
467 scenario we calculate a score. This score is the addition of individual
468 tests considered on the last 10 runs according to a defined criteria.
470 If we consider for instance a scenario os-odl_l2-nofeature-ha, we will
471 consider for the scoring all the runnable tests from the first test
472 categories (tiers healthcheck, smoke, controller and feature)
473 corresponding to this scenario.
476 +---------------------+---------+---------+---------+---------+
477 | Test | Apex | Compass | Fuel | Joid |
478 +=====================+=========+=========+=========+=========+
479 | vPing_ssh | X | X | X | X |
480 +---------------------+---------+---------+---------+---------+
481 | vPing_userdata | X | X | X | X |
482 +---------------------+---------+---------+---------+---------+
483 | tempest_smoke_serial| X | X | X | X |
484 +---------------------+---------+---------+---------+---------+
485 | rally_sanity | X | X | X | X |
486 +---------------------+---------+---------+---------+---------+
487 | odl | X | X | X | X |
488 +---------------------+---------+---------+---------+---------+
489 | promise | | | X | X |
490 +---------------------+---------+---------+---------+---------+
491 | security_scan | X | | | |
492 +---------------------+---------+---------+---------+---------+
493 | copper | X | | | X |
494 +---------------------+---------+---------+---------+---------+
496 All the testcases listed in the table are runnable on
497 os-odl_l2-nofeature scenarios.
498 If no results are available or if all the results are failed, the test
500 If it was succesfull at least once but no anymore during the 4 runs,
501 the case get 1 point (it worked once).
502 If at least 3 of the last 4 runs were successful, the case get 2 points.
503 If the last 4 runs of the test are successful, the test get 3 points.
505 In the example above, the target score for fuel/os-odl_l2-nofeature-ha
508 The scenario is validated per installer when we got 3 points for all
509 individual test cases (e.g 18/18).
510 Please note that complex or long duration tests are not considered for
511 the scoring. Such cases will be also get points, but these points will
512 be indicative and not used for the scenario validation.
514 A web page is automatically generated every day to display the status.
515 This page can be found at `[9]`_. For the status, click on Status menu,
516 you may also get feedback for vims and tempest_smoke_serial test cases.
518 Any validated scenario is stored in a local file on the web server. In
519 fact as we are using a sliding windows to get results, it may happen
520 that a successfull scenarios is not more run (because considered as
521 stable)and then the number of iterations (need 4) would not be
522 sufficient to get the green status.
524 Please note that other test cases e.g. sfc_odl, bgpvpn, moon) need also
525 ODL configuration addons and as a consequence specific scenario.
526 There are not considered as runnable on the generic odl_l2 scenario.
535 The installation and configuration of the Functest docker image is
538 The procedure to start tests is described in `[2]`_
541 How can I contribute to Functest?
542 =================================
544 If you are already a contributor of any OPNFV project, you can
545 contribute to functest. If you are totally new to OPNFV, you must first
546 create your Linux Foundation account, then contact us in order to
547 declare you in the repository database.
549 We distinguish 2 levels of contributors: the standard contributor can
550 push patch and vote +1/0/-1 on any Functest patch. The commitor can vote
551 -2/-1/0/+1/+2 and merge.
552 Functest commitors are promoted by the Functest contributors.
555 Where can I find some help to start?
556 ====================================
558 This guide is made for you. You can also have a look at the project wiki
560 There are references on documentation, video tutorials, tips...
562 You can also directly contact us by mail with [Functest] prefix at
563 opnfv-tech-discuss@lists.opnfv.org or on the IRC chan #opnfv-functest.
566 What kind of testing do you do in Functest?
567 ===========================================
569 Functest is focusing on Functional testing. The results must be PASS or
570 FAILED. We do not deal with performance and/or qualification tests.
571 We consider OPNFV as a black box and execute our tests from the jumphost
572 according to Pharos reference technical architecture.
574 Upstream test suites are integrated (Rally/Tempest/ODL/ONOS,...).
575 If needed Functest may bootstrap temporarily testing activities if they
576 are identified but not covered yet by an existing testing project (e.g
577 security_scan before the creation of the security reporistory)
580 How test constraints are defined?
581 =================================
583 Test constraints are defined according to 2 paramaters:
585 * the scenario (DEPLOY_SCENARIO env variable)
586 * the installer (INSTALLER_TYPE env variable)
588 A scenario is a formal description of the system under test.
589 The rules to define a scenario are described in `[4]`_
591 These 2 constraints are considered to determinate if the test is runnable
592 or not (e.g. no need to run onos suite on odl scenario).
594 In the test declaration for CI, the test owner shall indicate these 2
595 constraints. The file testcases.yaml `[5]`_ must be patched in git to
596 include new test cases. A more elaborated system based on template is
597 planned for next releases
599 For each dependency, it is possible to define a regex::
602 criteria: 'success_rate == 100%'
604 Test suite from Promise project.
606 installer: '(fuel)|(joid)'
609 In the example above, it means that promise test will be runnable only
610 with joid or fuel installers on any scenario.
612 The vims criteria means any installer and exclude onos and odl with
616 criteria: 'status == "PASS"'
618 This test case deploys an OpenSource vIMS solution from Clearwater
619 using the Cloudify orchestrator. It also runs some signaling traffic.
622 scenario: '(ocl)|(nosdn)|^(os-odl)((?!bgpvpn).)*$'
627 How to write and check constaint regex?
628 =======================================
630 Regex are standard regex. You can have a look at `[11]`_
632 You caa also easily test your regex via an online regex checker such as
634 Put your scenario in the TEST STRING window (e.g. os-odl_l3-ovs-ha), put
635 your regex in the REGULAR EXPRESSION window, then you can test your rule
639 How to know which test I can run?
640 =================================
642 You can use the API `[13]`_. The static declaration is in git `[5]`_
644 If you are in a Functest docker container (assuming that the
645 environement has been prepared): just use the new CLI.
647 You can get the list per Test cases or by Tier::
649 # functest testcase list
658 tempest_full_parallel
665 ['vping_ssh', 'vping_userdata', 'tempest_smoke_serial', 'rally_sanity']
669 ['doctor', 'security_scan']
671 ['tempest_full_parallel', 'rally_full']
676 How to manually start Functest test?
677 ====================================
679 Assuming that you are connected on the jumhost and that the system is
680 "Pharos compliant", i.e the technical architecture is compatible with
681 the one defined in the Pharos project::
683 # docker pull opnfv/functest:latest
684 # envs="-e INSTALLER_TYPE=fuel -e INSTALLER_IP=10.20.0.2 -e DEPLOY_SCENARIO=os-odl_l2-nofeature-ha -e CI_DEBUG=true"
685 # sudo docker run --privileged=true -id ${envs} opnfv/functest:latest /bin/bash
688 Then you must connect to the docker container and source the
691 # docker ps (copy the id)
692 # docker exec -ti <container_id> bash
696 You must first check if the environment is ready::
698 # functest env status
699 Functest environment ready to run tests.
702 If not ready, prepare the env by launching::
704 # functest env prepare
705 Functest environment ready to run tests.
707 Once the Functest env is ready, you can use the CLI to start tests.
709 You can run test cases per test case or per tier:
710 # functest testcase run <case name> or # functest tier run <tier name>
715 # functest testcase run tempest_smoke_serial
716 # functest tier run features
719 If you want to run all the tests you can type::
721 # functest testcase run all
724 If you want to run all the tiers (same at the end that running all the
725 test cases) you can type::
727 # functest tier run all
730 How to declare my tests in Functest?
731 ====================================
733 If you want to add new internal test cases, you can submit patch under
734 the testcases directory of Functest reporsitory.
736 For feature test integration, the code can be kept into your own
737 repository. Then the files of the Functest repository you must modify to
738 integrate Functest are:
740 * functest/docker/Dockerfile: get your code in Functest container
741 * functest/ci/testcases.yaml: reference your test and its associated constraints
742 * functest/ci/exec_test.sh: run your test from CI and CLI
748 This file lists the repositories to be cloned in the Functest container.
749 The repositories can be internal or external::
751 RUN git clone https://gerrit.opnfv.org/gerrit/<your project> ${repos_dir}/<your project>
756 All the test cases that must be run from CI / CLI must be declared in
758 This file is used to get the constraintes related to the test::
760 name: <my_super_test_case>
761 criteria: <not used yet in Colorado, could be > 'PASS', 'rate > 90%'
763 <the description of your super test suite>
765 installer: regex related to installer e.g. 'fuel', '(apex)||(joid)'
766 scenario: regex related to the scenario e.g. 'ovs*no-ha'
769 You must declare your test case in one of the category (tier).
771 If you are integrating test suites from a feature project, the category
778 This file is used to start your test. It is used in CI but also by the
781 You just patch the file in git and add a line::
784 "<my_super_test_case>")
785 python ${FUNCTEST_REPO_DIR}/testcases/features/mycase.py
789 Note you can use python or bash scripts.
792 How to select my list of tests for CI?
793 ======================================
795 Functest can be run automatically from CI, a jenkins job is usually
796 called after an OPNFV fresh installation.
797 By default we try to run all the possible tests (see `[14]` called from
798 Functest jenkins job)::
800 cmd="python ${FUNCTEST_REPO_DIR}/ci/run_tests.py -t all ${flags}"
803 Each case can be configured as daily and/or weekly task.
804 When executing run_tests.py a check based on the jenkins build tag will
805 be considered to detect whether it is a daily and/or a weekly test.
807 in your CI you can customize the list of test you want to run by case or
808 by tier, just change the line::
810 cmd="python ${FUNCTEST_REPO_DIR}/ci/run_tests.py -t <whatever you want> ${flags}"
814 cmd="python ${FUNCTEST_REPO_DIR}/ci/run_tests.py -t healthcheck,smoke ${flags}"
816 This command will run all the test cases of the first 2 tiers, i.e.
817 healthcheck, vping_ssh, vping_userdata, tempest_smoke_serial and
821 How to push your results into the Test Database
822 ===============================================
824 The test database is used to collect test results. By default it is
825 enabled only for CI tests from Production CI pods.
827 The architecture and associated API is described in previous chapter.
828 If you want to push your results from CI, you just have to use the API
829 at the end of your script.
831 You can also reuse a python function defined in functest_utils.py::
833 def push_results_to_db(db_url, case_name, logger, pod_name,version, payload):
835 POST results to the Result target DB
837 url = db_url + "/results"
838 installer = get_installer_type(logger)
839 params = {"project_name": "functest", "case_name": case_name,
840 "pod_name": pod_name, "installer": installer,
841 "version": version, "details": payload}
843 headers = {'Content-Type': 'application/json'}
845 r = requests.post(url, data=json.dumps(params), headers=headers)
850 print "Error [push_results_to_db('%s', '%s', '%s', '%s', '%s')]:" \
851 % (db_url, case_name, pod_name, version, payload), e
859 .. _`[1]`: http://artifacts.opnfv.org/functest/docs/configguide/index.html Functest configuration guide URL
860 .. _`[2]`: http://artifacts.opnfv.org/functest/docs/userguide/index.html functest user guide URL
861 .. _`[3]`: https://wiki.opnfv.org/opnfv_test_dashboard
862 .. _`[4]`: https://wiki.opnfv.org/display/INF/CI+Scenario+Naming
863 .. _`[5]`: https://git.opnfv.org/cgit/functest/tree/ci/testcases.yaml
864 .. _`[6]`: https://git.opnfv.org/cgit/releng/tree/utils/test/result_collection_api
865 .. _`[7]`: https://git.opnfv.org/cgit/releng/tree/utils/test/scripts
866 .. _`[8]`: https://git.opnfv.org/cgit/releng/tree/utils/test/reporting/functest
867 .. _`[9]`: http://testresults.opnfv.org/reporting/
868 .. _`[10]`: https://wiki.opnfv.org/opnfv_functional_testing
869 .. _`[11]`: https://docs.python.org/2/howto/regex.html
870 .. _`[12]`: https://regex101.com/
871 .. _`[13]`: http://testresults.opnfv.org/test/api/v1/projects/functest/cases
872 .. _`[14]`: https://git.opnfv.org/cgit/releng/tree/jjb/functest/functest-daily.sh
873 OPNFV main site: opnfvmain_.
875 OPNFV functional test page: opnfvfunctest_.
877 IRC support chan: #opnfv-testperf
879 .. _opnfvmain: http://www.opnfv.org
880 .. _opnfvfunctest: https://wiki.opnfv.org/opnfv_functional_testing
881 .. _`OpenRC`: http://docs.openstack.org/user-guide/common/cli_set_environment_variables_using_openstack_rc.html
882 .. _`Rally installation procedure`: https://rally.readthedocs.org/en/latest/tutorial/step_0_installation.html
883 .. _`config_test.py` : https://git.opnfv.org/cgit/functest/tree/testcases/config_functest.py
884 .. _`config_functest.yaml` : https://git.opnfv.org/cgit/functest/tree/testcases/config_functest.yaml