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 and VNF onboarding project testing.
17 Functest developed a TestAPI 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 Danube are:
72 * tempest_smoke_serial
74 * tempest_full_parallel
78 By internal, we mean that this particular test cases have been
79 developped and/or integrated by functest contributors and the associated
80 code is hosted in the Functest repository.
81 An internal case can be fully developped or a simple integration of
82 upstream suites (e.g. Tempest/Rally developped in OpenStack are just
83 integrated in Functest).
84 The structure of this repository is detailed in `[1]`_.
85 The main internal test cases are in the opnfv_tests subfolder of the
86 repository, the internal test cases are:
89 * openstack: healthcheck, vping_ssh, vping_userdata, tempest_*, rally_*, connection_check, api_check, snaps_smoke
92 If you want to create a new test case you will have to create a new
93 folder under the testcases directory.
95 Functest external test cases
96 ============================
97 The external test cases are inherited from other OPNFV projects,
98 especially the feature projects.
100 The external test cases are:
117 The code to run these test cases may be directly in the repository of
118 the project. We have also a **features** sub directory under opnfv_tests
119 directory that may be used (it can be usefull if you want to reuse
125 Functest can be considered as a framework.
126 Functest is release as a docker file, including tools, scripts and a CLI
127 to prepare the environement and run tests.
128 It simplifies the integration of external test suites in CI pipeline
129 and provide commodity tools to collect and display results.
131 Since Colorado, test categories also known as tiers have been created to
132 group similar tests, provide consistant sub-lists and at the end optimize
133 test duration for CI (see How To section).
135 The definition of the tiers has been agreed by the testing working group.
146 Functest abstraction classes
147 ============================
149 In order to harmonize test integration, 3 abstraction classes have been
150 introduced in Danube:
152 * testcase_base: base for any test case
153 * feature_base: abstraction for feature project
154 * vnf_base: abstraction for vnf onboarding
156 The goal is to unify the way to run test from Functest.
158 feature_base and vnf_base inherit from testcase_base.
160 +-----------------------------------------+
166 | - publish_report() |
167 | - check_criteria() |
169 +-----------------------------------------+
172 +--------------------+ +--------------------------+
174 | feature_base | | vnf_base |
176 | - prepare() | | - prepare() |
177 | - post() | | - deploy_orchestrator() |
178 | - parse_results() | | - deploy_vnf() |
183 +--------------------+ +--------------------------+
186 Functest util classes
187 =====================
189 In order to simplify the creation of test cases, Functest develops some
190 functions that can be used by any feature or internal test cases.
191 Several features are supported such as logger, configuration management and
192 Openstack capabilities (snapshot, clean, tacker,..).
193 These functions can be found under <repo>/functest/utils and can be described as
200 |-- functest_logger.py
201 |-- functest_utils.py
202 |-- openstack_clean.py
203 |-- openstack_snapshot.py
204 |-- openstack_tacker.py
205 `-- openstack_utils.py
207 Note that for Openstack, keystone v3 is now deployed by default by compass,
208 fuel and joid in Danube. All installers still support keysone v2 (deprecated in
211 Test collection framework
212 =========================
214 The OPNFV testing group created a test collection database to collect
215 the test results from CI:
218 http://testresults.opnfv.org/test/swagger/spec.html
220 Authentication: opnfv/api@opnfv
222 Any test project running on any lab integrated in CI can push the
223 results to this database.
224 This database can be used to see the evolution of the tests and compare
225 the results versus the installers, the scenarios or the labs.
230 The Test result management can be summarized as follows::
232 +-------------+ +-------------+ +-------------+
234 | Test | | Test | | Test |
235 | Project #1 | | Project #2 | | Project #N |
237 +-------------+ +-------------+ +-------------+
240 +-----------------------------------------+
242 | Test Rest API front end |
243 | http://testresults.opnfv.org/test |
245 +-----------------------------------------+
248 | +-------------------------+
250 | | Test Results DB |
253 | +-------------------------+
256 +----------------------+
260 +----------------------+
264 The TestAPI is used to declare pods, projects, test cases and test
265 results. Pods are the pods used to run the tests.
266 The results pushed in the database are related to pods, projects and
267 cases. If you try to push results of test done on non referenced pod,
268 the API will return an error message.
270 An additional method dashboard has been added to post-process
271 the raw results in release Brahmaputra (deprecated in Colorado).
273 The data model is very basic, 4 objects are created:
284 "details": <URL description of the POD>,
285 "creation_date": "YYYY-MM-DD HH:MM:SS",
286 "name": <The POD Name>,
287 "mode": <metal or virtual>,
288 "role": <ci-pod or community-pod or single-node>
295 "name": <Name of the Project>,
296 "creation_date": "YYYY-MM-DD HH:MM:SS",
297 "description": <Short description>
304 "name":<Name of the test case>,
305 "project_name":<Name of belonged project>,
306 "creation_date": "YYYY-MM-DD HH:MM:SS",
307 "description": <short description>,
308 "url":<URL for longer description>
315 "case_name": <Reference to the test case>,
316 "project_name": <Reference to project>,
317 "pod_name": <Reference to POD where the test was executed>,
318 "installer": <Installer Apex or Compass or Fuel or Joid>,
319 "version": <master or Colorado or Brahmaputra>,
320 "start_date": "YYYY-MM-DD HH:MM:SS",
321 "stop_date": "YYYY-MM-DD HH:MM:SS",
322 "build_tag": <such as "jenkins-functest-fuel-baremetal-daily-master-108">,
323 "scenario": <Scenario on which the test was executed>,
324 "criteria": <PASS or FAILED>,
331 The API can described as follows. For detailed information, please go to
333 http://testresults.opnfv.org/test/swagger/spec.html
335 Authentication: opnfv/api@opnfv
339 +--------+--------------------------+-----------------------------------------+
340 | Method | Path | Description |
341 +========+==========================+=========================================+
342 | GET | /versions | Get all supported API versions |
343 +--------+--------------------------+-----------------------------------------+
348 +--------+----------------------------+-----------------------------------------+
349 | Method | Path | Description |
350 +========+============================+=========================================+
351 | GET | /api/v1/pods | Get the list of declared Labs (PODs) |
352 +--------+----------------------------+-----------------------------------------+
353 | POST | /api/v1/pods | Declare a new POD |
354 | | | Content-Type: application/json |
356 | | | "name": "pod_foo", |
357 | | | "mode": "metal", |
358 | | | "role": "ci-pod", |
359 | | | "details": "it is a ci pod" |
361 +--------+----------------------------+-----------------------------------------+
362 | GET | /api/v1/pods/{pod_name} | Get a declared POD |
363 +--------+----------------------------+-----------------------------------------+
367 +--------+----------------------------+-----------------------------------------+
368 | Method | Path | Description |
369 +========+============================+=========================================+
370 | GET | /api/v1/projects | Get the list of declared projects |
371 +--------+----------------------------+-----------------------------------------+
372 | POST | /api/v1/projects | Declare a new test project |
373 | | | Content-Type: application/json |
375 | | | "name": "project_foo", |
376 | | | "description": "whatever you want" |
378 +--------+----------------------------+-----------------------------------------+
379 | DELETE | /api/v1/projects/{project} | Delete a test project |
380 +--------+----------------------------+-----------------------------------------+
381 | GET | /api/v1/projects/{project} | Get details on a {project} |
383 +--------+----------------------------+-----------------------------------------+
384 | PUT | /api/v1/projects/{project} | Update a test project |
386 | | | Content-Type: application/json |
388 | | | <the field(s) you want to modify> |
390 +--------+----------------------------+-----------------------------------------+
395 +--------+----------------------------+-----------------------------------------+
396 | Method | Path | Description |
397 +========+============================+=========================================+
398 | GET | /api/v1/projects/{project}/| Get the list of testcases of {project} |
400 +--------+----------------------------+-----------------------------------------+
401 | POST | /api/v1/projects/{project}/| Add a new test case to {project} |
402 | | cases | Content-Type: application/json |
404 | | | "name": "case_foo", |
405 | | | "description": "whatever you want" |
406 | | | "url": "whatever you want" |
408 +--------+----------------------------+-----------------------------------------+
409 | DELETE | /api/v1/projects/{project}/| Delete a test case |
411 +--------+----------------------------+-----------------------------------------+
412 | GET | /api/v1/projects/{project}/| Get a declared test case |
414 +--------+----------------------------+-----------------------------------------+
415 | PUT | /api/v1/projects/{project}?| Modify a test case of {project} |
417 | | | Content-Type: application/json |
419 | | | <the field(s) you want to modify> |
421 +--------+----------------------------+-----------------------------------------+
425 +--------+----------------------------+------------------------------------------+
426 | Method | Path | Description |
427 +========+============================+==========================================+
428 | GET | /api/v1/results | Get all the test results |
429 +--------+----------------------------+------------------------------------------+
430 | POST | /api/v1/results | Add a new test results |
431 | | | Content-Type: application/json |
433 | | | "project_name": "project_foo", |
434 | | | "scenario": "odl-l2", |
435 | | | "stop_date": "2016-05-28T14:42:58.384Z", |
436 | | | "trust_indicator": 0.5, |
437 | | | "case_name": "vPing", |
438 | | | "build_tag": "", |
439 | | | "version": "Colorado", |
440 | | | "pod_name": "pod_foo", |
441 | | | "criteria": "PASS", |
442 | | | "installer": "fuel", |
443 | | | "start_date": "2016-05-28T14:41:58.384Z",|
444 | | | "details": <your results> |
446 +--------+----------------------------+------------------------------------------+
447 | GET | /api/v1/results? | Get the test results of {case} |
449 +--------+----------------------------+------------------------------------------+
450 | GET | /api/v1/results? | Get the test results of build_tag |
451 | | build_tag={tag} | {tag}. |
452 +--------+----------------------------+------------------------------------------+
453 | GET | /api/v1/results? | Get last {N} records of test results |
455 +--------+----------------------------+------------------------------------------+
456 | GET | /api/v1/results? | Get the test results of scenario |
457 | | scenario={scenario} | {scenario}. |
458 +--------+----------------------------+------------------------------------------+
459 | GET | /api/v1/results? | Get the test results of trust_indicator |
460 | | trust_indicator={ind} | {ind}. |
461 +--------+----------------------------+------------------------------------------+
462 | GET | /api/v1/results? | Get the test results of last days |
463 | | period={period} | {period}. |
464 +--------+----------------------------+------------------------------------------+
465 | GET | /api/v1/results? | Get the test results of {project} |
466 | | project={project} | |
467 +--------+----------------------------+------------------------------------------+
468 | GET | /api/v1/results? | Get the test results of version |
469 | | version={version} | {version}. |
470 +--------+----------------------------+------------------------------------------+
471 | GET | /api/v1/results? | Get the test results of criteria |
472 | | criteria={criteria} | {criteria}. |
473 +--------+----------------------------+------------------------------------------+
474 | GET | /api/v1/results? | get the results on pod {pod} |
476 +--------+----------------------------+------------------------------------------+
477 | GET | /api/v1/results? | Get the test results of installer {inst} |
478 | | installer={inst} | |
479 +--------+----------------------------+------------------------------------------+
480 | GET | /api/v1/results? | Get the results according to combined |
481 | | <query conditions> | query conditions supported above |
482 +--------+----------------------------+------------------------------------------+
483 | GET | /api/v1/results/{result_id}| Get the test result by result_id |
484 +--------+----------------------------+------------------------------------------+
488 +--------+----------------------------+-----------------------------------------+
489 | Method | Path | Description |
490 +========+============================+=========================================+
491 | GET | /api/v1/scenarios | Get the list of declared scenarios |
492 +--------+----------------------------+-----------------------------------------+
493 | POST | /api/v1/scenario | Declare a new scenario |
494 +--------+----------------------------+-----------------------------------------+
495 | GET | /api/v1/scenario? | Get a declared scenario |
496 | | <query conditions> | |
497 +--------+----------------------------+-----------------------------------------+
500 The code of the API is hosted in the releng repository `[6]`_.
501 The static documentation of the API can be found at `[17]`_.
502 The TestAPI has been dockerized and may be installed locally in your
503 lab. See `[15]`_ for details.
505 The deployment of the TestAPI has been automated.
506 A jenkins job manages:
507 * the unit tests of the TestAPI
508 * the creation of a new docker file
509 * the deployment of the new TestAPI
510 * the archive of the old TestAPI
511 * the backup of the Mongo DB
513 TestAPI Authorization
514 ~~~~~~~~~~~~~~~~~~~~~
516 PUT/DELETE/POST operations of the TestAPI now require token based authorization. The token needs
517 to be added in the request using a header 'X-Auth-Token' for access to the database.
520 headers['X-Auth-Token']
522 The value of the header i.e the token can be accessed in the jenkins environment variable
523 *TestApiToken*. The token value is added as a masked password.
525 .. code-block:: python
527 headers['X-Auth-Token'] = os.environ.get('TestApiToken')
529 The above example is in Python. Token based authentication has been added so that only ci pods
530 jenkins job can have access to the database.
532 Please note that currently token authorization is implemented but is not yet enabled.
537 An automatic reporting page has been created in order to provide a
538 consistant view of the scenarios.
539 In this page, each scenario is evaluated according to test criteria.
540 The code for the automatic reporting is available at `[8]`_.
542 The results are collected from the centralized database every day and,
543 per scenario. A score is calculated based on the results from the last
544 10 days. This score is the addition of single test scores. Each test
545 case has a success criteria reflected in the criteria field from the
548 Considering an instance of a scenario os-odl_l2-nofeature-ha, the
549 scoring is the addition of the scores of all the runnable tests from the
550 categories (tiers healthcheck, smoke and features)
551 corresponding to this scenario.
554 +---------------------+---------+---------+---------+---------+
555 | Test | Apex | Compass | Fuel | Joid |
556 +=====================+=========+=========+=========+=========+
557 | vPing_ssh | X | X | X | X |
558 +---------------------+---------+---------+---------+---------+
559 | vPing_userdata | X | X | X | X |
560 +---------------------+---------+---------+---------+---------+
561 | tempest_smoke_serial| X | X | X | X |
562 +---------------------+---------+---------+---------+---------+
563 | rally_sanity | X | X | X | X |
564 +---------------------+---------+---------+---------+---------+
565 | odl | X | X | X | X |
566 +---------------------+---------+---------+---------+---------+
567 | promise | | | X | X |
568 +---------------------+---------+---------+---------+---------+
569 | doctor | X | | X | |
570 +---------------------+---------+---------+---------+---------+
571 | security_scan | X | | | |
572 +---------------------+---------+---------+---------+---------+
574 +---------------------+---------+---------+---------+---------+
575 | copper | X | | | X |
576 +---------------------+---------+---------+---------+---------+
578 All the testcases listed in the table are runnable on
579 os-odl_l2-nofeature scenarios.
580 If no result is available or if all the results are failed, the test
582 If it was succesfull at least once but not anymore during the 4 runs,
583 the case get 1 point (it worked once).
584 If at least 3 of the last 4 runs were successful, the case get 2 points.
585 If the last 4 runs of the test are successful, the test get 3 points.
587 In the example above, the target score for fuel/os-odl_l2-nofeature-ha
590 The scenario is validated per installer when we got 3 points for all
591 individual test cases (e.g 18/18).
592 Please note that complex or long duration tests are not considered for
593 the scoring. The success criteria are not always easy to define and may
594 require specific hardware configuration. These results however provide
595 a good level of trust on the scenario.
597 A web page is automatically generated every day to display the status.
598 This page can be found at `[9]`_. For the status, click on Status menu,
599 you may also get feedback for vims and tempest_smoke_serial test cases.
601 Any validated scenario is stored in a local file on the web server. In
602 fact as we are using a sliding windows to get results, it may happen
603 that a successful scenarios is no more run (because considered as
604 stable) and then the number of iterations (4 needed) would not be
605 sufficient to get the green status.
607 Please note that other test cases (e.g. sfc_odl, bgpvpn) need also
608 ODL configuration addons and as a consequence specific scenario.
609 There are not considered as runnable on the generic odl_l2 scenario.
614 Dashboard is used to provide a consistant view of the results collected
616 The results showed on the dashboard are post processed from the Database,
617 which only contains raw results.
619 In Brahmaputra, we created a basic dashboard.
620 Since Colorado, it was decided to adopt ELK framework. Mongo DB results
621 are extracted to feed Elasticsearch database (`[7]`_).
623 A script was developed to build elasticsearch data set. This
624 script can be found in `[16]`_.
626 For next versions, it was decided to integrated bitergia dashboard.
627 Bitergia already provides a dashboard for code and infrastructure.
628 A new Test tab will be added. The dataset will be built by consuming
639 The installation and configuration of the Functest docker image is
642 The procedure to start tests is described in `[2]`_
645 How can I contribute to Functest?
646 =================================
648 If you are already a contributor of any OPNFV project, you can
649 contribute to functest. If you are totally new to OPNFV, you must first
650 create your Linux Foundation account, then contact us in order to
651 declare you in the repository database.
653 We distinguish 2 levels of contributors:
655 * the standard contributor can push patch and vote +1/0/-1 on any Functest patch
656 * The commitor can vote -2/-1/0/+1/+2 and merge
658 Functest commitors are promoted by the Functest contributors.
661 Where can I find some help to start?
662 ====================================
664 This guide is made for you. You can also have a look at the project wiki
666 There are references on documentation, video tutorials, tips...
668 You can also directly contact us by mail with [Functest] prefix in the
669 title at opnfv-tech-discuss@lists.opnfv.org or on the IRC chan
673 What kind of testing do you do in Functest?
674 ===========================================
676 Functest is focusing on Functional testing. The results must be PASS or
677 FAIL. We do not deal with performance and/or qualification tests.
678 We consider OPNFV as a black box and execute our tests from the jumphost
679 according to Pharos reference technical architecture.
681 Upstream test suites are integrated (Rally/Tempest/ODL/ONOS,...).
682 If needed Functest may bootstrap temporarily testing activities if they
683 are identified but not covered yet by an existing testing project (e.g
684 security_scan before the creation of the security repository)
687 How test constraints are defined?
688 =================================
690 Test constraints are defined according to 2 paramaters:
692 * The scenario (DEPLOY_SCENARIO env variable)
693 * The installer (INSTALLER_TYPE env variable)
695 A scenario is a formal description of the system under test.
696 The rules to define a scenario are described in `[4]`_
698 These 2 constraints are considered to determinate if the test is runnable
699 or not (e.g. no need to run onos suite on odl scenario).
701 In the test declaration for CI, the test owner shall indicate these 2
702 constraints. The file testcases.yaml `[5]`_ must be patched in git to
703 include new test cases. A more elaborated system based on template is
704 planned for next releases
706 For each dependency, it is possible to define a regex::
709 criteria: 'success_rate == 100%'
711 Test suite from Promise project.
713 installer: '(fuel)|(joid)'
716 In the example above, it means that promise test will be runnable only
717 with joid or fuel installers on any scenario.
719 The vims criteria means any installer and exclude onos and odl with
723 criteria: 'status == "PASS"'
725 This test case deploys an OpenSource vIMS solution from Clearwater
726 using the Cloudify orchestrator. It also runs some signaling traffic.
729 scenario: '(ocl)|(nosdn)|^(os-odl)((?!bgpvpn).)*$'
732 How to write and check constaint regex?
733 =======================================
735 Regex are standard regex. You can have a look at `[11]`_
737 You can also easily test your regex via an online regex checker such as `[12]`_.
738 Put your scenario in the TEST STRING window (e.g. os-odl_l3-ovs-ha), put
739 your regex in the REGULAR EXPRESSION window, then you can test your rule
743 How to know which test I can run?
744 =================================
746 You can use the API `[13]`_. The static declaration is in git `[5]`_
748 If you are in a Functest docker container (assuming that the
749 environement has been prepared): just use the CLI.
751 You can get the list per Test cases or by Tier::
753 # functest testcase list
762 tempest_full_parallel
769 ['vping_ssh', 'vping_userdata', 'tempest_smoke_serial', 'rally_sanity']
773 ['doctor', 'security_scan']
775 ['tempest_full_parallel', 'rally_full']
780 How to manually start Functest tests?
781 =====================================
783 Assuming that you are connected on the jumphost and that the system is
784 "Pharos compliant", i.e the technical architecture is compatible with
785 the one defined in the Pharos project::
787 # docker pull opnfv/functest:latest
788 # envs="-e INSTALLER_TYPE=fuel -e INSTALLER_IP=10.20.0.2 -e DEPLOY_SCENARIO=os-odl_l2-nofeature-ha -e CI_DEBUG=true"
789 # sudo docker run --privileged=true -id ${envs} opnfv/functest:latest /bin/bash
792 Then you must connect to the docker container and source the
795 # docker ps (copy the id)
796 # docker exec -ti <container_id> bash
800 You must first check if the environment is ready::
802 # functest env status
803 Functest environment ready to run tests.
806 If not ready, prepare the env by launching::
808 # functest env prepare
809 Functest environment ready to run tests.
811 Once the Functest env is ready, you can use the CLI to start tests.
813 You can run test cases per test case or per tier:
814 # functest testcase run <case name> or # functest tier run <tier name>
819 # functest testcase run tempest_smoke_serial
820 # functest tier run features
823 If you want to run all the tests you can type::
825 # functest testcase run all
828 If you want to run all the tiers (same at the end that running all the
829 test cases) you can type::
831 # functest tier run all
834 How to declare my tests in Functest?
835 ====================================
837 If you want to add new internal test cases, you can submit patch under
838 the testcases directory of Functest repository.
840 For feature test integration, the code can be kept into your own
841 repository. The Functest files to be modified are:
843 * functest/docker/Dockerfile: get your code in Functest container
844 * functest/ci/testcases.yaml: reference your test and its associated constraints
850 This file lists the repositories (internal or external) to be cloned in
851 the Functest container. You can also add external packages::
853 RUN git clone https://gerrit.opnfv.org/gerrit/<your project> ${REPOS_DIR}/<your project>
858 All the test cases that must be run from CI / CLI must be declared in
861 This file is used to get the constraints related to the test::
863 name: <my_super_test_case>
864 criteria: <not used yet in Colorado, could be > 'PASS', 'rate > 90%'
866 <the description of your super test suite>
868 installer: regex related to installer e.g. 'fuel', '(apex)||(joid)'
869 scenario: regex related to the scenario e.g. 'ovs*no-ha'
872 You must declare your test case in one of the category (tier).
874 If you are integrating test suites from a feature project, the default
875 category is **features**.
878 How to select my list of tests for CI?
879 ======================================
881 Functest can be run automatically from CI, a jenkins job is usually
882 called after an OPNFV fresh installation.
883 By default we try to run all the possible tests (see `[14]` called from
884 Functest jenkins job)::
886 cmd="python ${FUNCTEST_REPO_DIR}/ci/run_tests.py -t all ${flags}"
889 Each case can be configured as daily and/or weekly task.
890 Weekly tasks are used for long duration or experimental tests.
891 Daily tasks correspond to the minimum set of test suites to validate a scenario.
893 When executing run_tests.py, a check based on the jenkins build tag will
894 be considered to detect whether it is a daily and/or a weekly test.
896 in your CI you can customize the list of test you want to run by case or
897 by tier, just change the line::
899 cmd="python ${FUNCTEST_REPO_DIR}/ci/run_tests.py -t <whatever you want> ${flags}"
903 cmd="python ${FUNCTEST_REPO_DIR}/ci/run_tests.py -t healthcheck,smoke ${flags}"
905 This command will run all the test cases of the first 2 tiers, i.e.
906 healthcheck, connection_check, api_check, vping_ssh, vping_userdata,
907 snaps_somke, tempest_smoke_serial and rally_sanity.
910 How to push your results into the Test Database
911 ===============================================
913 The test database is used to collect test results. By default it is
914 enabled only for CI tests from Production CI pods.
916 The architecture and associated API is described in previous chapter.
917 If you want to push your results from CI, you just have to call the API
918 at the end of your script.
920 You can also reuse a python function defined in functest_utils.py::
922 def push_results_to_db(db_url, case_name, logger, pod_name,version, payload):
924 POST results to the Result target DB
926 url = db_url + "/results"
927 installer = get_installer_type(logger)
928 params = {"project_name": "functest", "case_name": case_name,
929 "pod_name": pod_name, "installer": installer,
930 "version": version, "details": payload}
932 headers = {'Content-Type': 'application/json'}
934 r = requests.post(url, data=json.dumps(params), headers=headers)
939 print "Error [push_results_to_db('%s', '%s', '%s', '%s', '%s')]:" \
940 % (db_url, case_name, pod_name, version, payload), e
948 _`[1]`: http://artifacts.opnfv.org/functest/docs/configguide/index.html Functest configuration guide
950 _`[2]`: http://artifacts.opnfv.org/functest/docs/userguide/index.html functest user guide
952 _`[3]`: https://wiki.opnfv.org/opnfv_test_dashboard Brahmaputra dashboard
954 _`[4]`: https://wiki.opnfv.org/display/INF/CI+Scenario+Naming
956 _`[5]`: https://git.opnfv.org/cgit/functest/tree/ci/testcases.yaml
958 _`[6]`: https://git.opnfv.org/cgit/releng/tree/utils/test/result_collection_api
960 _`[7]`: https://git.opnfv.org/cgit/releng/tree/utils/test/scripts
962 _`[8]`: https://git.opnfv.org/cgit/releng/tree/utils/test/reporting/functest
964 _`[9]`: http://testresults.opnfv.org/reporting/
966 _`[10]`: https://wiki.opnfv.org/opnfv_functional_testing
968 _`[11]`: https://docs.python.org/2/howto/regex.html
970 _`[12]`: https://regex101.com/
972 _`[13]`: http://testresults.opnfv.org/test/api/v1/projects/functest/cases
974 _`[14]`: https://git.opnfv.org/cgit/releng/tree/jjb/functest/functest-daily.sh
976 _`[15]`: https://git.opnfv.org/cgit/releng/tree/utils/test/result_collection_api/README.rst
978 _`[16]`: https://git.opnfv.org/cgit/releng/tree/utils/test/scripts/mongo_to_elasticsearch.py
980 _`[17]`: http://artifacts.opnfv.org/releng/docs/testapi.html
982 OPNFV main site: http://www.opnfv.org
984 OPNFV functional test page: https://wiki.opnfv.org/opnfv_functional_testing
986 IRC support chan: #opnfv-functest
988 _`OpenRC`: http://docs.openstack.org/user-guide/common/cli_set_environment_variables_using_openstack_rc.html
990 _`Rally installation procedure`: https://rally.readthedocs.org/en/latest/tutorial/step_0_installation.html
992 _`config_functest.yaml` : https://git.opnfv.org/cgit/functest/tree/testcases/config_functest.yaml