1 .. This work is licensed under a Creative Commons Attribution 4.0 International License.
2 .. SPDX-License-Identifier: CC-BY-4.0
4 ******************************
5 OPNFV FUNCTEST developer guide
6 ******************************
17 Functest is a project dealing with functional testing.
18 Functest produces its own internal test cases but can also be considered
19 as a framework to support feature and VNF onboarding project testing.
20 Functest developed a TestAPI and defined a test collection framework
21 that can be used by any OPNFV project.
23 Therefore there are many ways to contribute to Functest. You can:
25 * Develop new internal test cases
26 * Integrate the tests from your feature project
27 * Develop the framework to ease the integration of external test cases
28 * Develop the API / Test collection framework
29 * Develop dashboards or automatic reporting portals
31 This document describes how, as a developer, you may interact with the
32 Functest project. The first section details the main working areas of
33 the project. The Second part is a list of "How to" to help you to join
34 the Functest family whatever your field of interest is.
37 ========================
38 Functest developer areas
39 ========================
42 Functest High level architecture
43 ================================
45 Functest is project delivering a test container dedicated to OPNFV.
46 It includes the tools, the scripts and the test scenarios.
48 Functest can be described as follow::
50 +----------------------+
52 | +--------------+ | +-------------------+
54 | | Tools | +------------------+ OPNFV |
55 | | Scripts | | | System Under Test |
56 | | Scenarios | +------------------+ |
57 | | | | Management | |
58 | +--------------+ | +-------------------+
62 +----------------------+
64 Functest internal test cases
65 ============================
66 The internal test cases in Danube are:
78 * tempest_full_parallel
79 * tempest_smoke_serial
81 By internal, we mean that this particular test cases have been
82 developped and/or integrated by functest contributors and the associated
83 code is hosted in the Functest repository.
84 An internal case can be fully developped or a simple integration of
85 upstream suites (e.g. Tempest/Rally developped in OpenStack are just
86 integrated in Functest).
87 The structure of this repository is detailed in `[1]`_.
88 The main internal test cases are in the opnfv_tests subfolder of the
89 repository, the internal test cases are:
92 * openstack: api_check, connection_check, snaps_health_check, vping_ssh, vping_userdata, tempest_*, rally_*, snaps_smoke
95 If you want to create a new test case you will have to create a new
96 folder under the testcases directory.
98 Functest external test cases
99 ============================
100 The external test cases are inherited from other OPNFV projects,
101 especially the feature projects.
103 The external test cases are:
124 The code to run these test cases may be directly in the repository of
125 the project. We have also a **features** sub directory under opnfv_tests
126 directory that may be used (it can be usefull if you want to reuse
132 Functest can be considered as a framework.
133 Functest is release as a docker file, including tools, scripts and a CLI
134 to prepare the environement and run tests.
135 It simplifies the integration of external test suites in CI pipeline
136 and provide commodity tools to collect and display results.
138 Since Colorado, test categories also known as tiers have been created to
139 group similar tests, provide consistant sub-lists and at the end optimize
140 test duration for CI (see How To section).
142 The definition of the tiers has been agreed by the testing working group.
153 Functest abstraction classes
154 ============================
156 In order to harmonize test integration, 3 abstraction classes have been
157 introduced in Danube:
159 * testcase: base for any test case
160 * feature_base: abstraction for feature project
161 * vnf_base: abstraction for vnf onboarding
163 The goal is to unify the way to run test from Functest.
165 feature_base and vnf_base inherit from testcase::
167 +-----------------------------------------+
173 | - publish_report() |
174 | - check_criteria() |
176 +-----------------------------------------+
179 +--------------------+ +--------------------------+
181 | feature_base | | vnf_base |
183 | - prepare() | | - prepare() |
184 | - execute() | | - deploy_orchestrator() |
185 | - post() | | - deploy_vnf() |
186 | - parse_results() | | - test_vnf() |
190 +--------------------+ +--------------------------+
193 Functest util classes
194 =====================
196 In order to simplify the creation of test cases, Functest develops some
197 functions that can be used by any feature or internal test cases.
198 Several features are supported such as logger, configuration management and
199 Openstack capabilities (snapshot, clean, tacker,..).
200 These functions can be found under <repo>/functest/utils and can be described as
207 |-- functest_logger.py
208 |-- functest_utils.py
209 |-- openstack_clean.py
210 |-- openstack_snapshot.py
211 |-- openstack_tacker.py
212 `-- openstack_utils.py
214 Note that for Openstack, keystone v3 is now deployed by default by compass,
215 fuel and joid in Danube. All installers still support keysone v2 (deprecated in
218 Test collection framework
219 =========================
221 The OPNFV testing group created a test collection database to collect
222 the test results from CI:
225 http://testresults.opnfv.org/test/swagger/spec.html
227 Authentication: opnfv/api@opnfv
229 Any test project running on any lab integrated in CI can push the
230 results to this database.
231 This database can be used to see the evolution of the tests and compare
232 the results versus the installers, the scenarios or the labs.
237 The Test result management can be summarized as follows::
239 +-------------+ +-------------+ +-------------+
241 | Test | | Test | | Test |
242 | Project #1 | | Project #2 | | Project #N |
244 +-------------+ +-------------+ +-------------+
247 +-----------------------------------------+
249 | Test Rest API front end |
250 | http://testresults.opnfv.org/test |
252 +-----------------------------------------+
255 | +-------------------------+
257 | | Test Results DB |
260 | +-------------------------+
263 +----------------------+
267 +----------------------+
271 The TestAPI is used to declare pods, projects, test cases and test
272 results. Pods are the pods used to run the tests.
273 The results pushed in the database are related to pods, projects and
274 cases. If you try to push results of test done on non referenced pod,
275 the API will return an error message.
277 An additional method dashboard has been added to post-process
278 the raw results in release Brahmaputra (deprecated in Colorado).
280 The data model is very basic, 5 objects are created:
288 The code of the API is hosted in the releng repository `[6]`_.
289 The static documentation of the API can be found at `[17]`_.
290 The TestAPI has been dockerized and may be installed locally in your
291 lab. See `[15]`_ for details.
293 The deployment of the TestAPI has been automated.
294 A jenkins job manages:
295 * the unit tests of the TestAPI
296 * the creation of a new docker file
297 * the deployment of the new TestAPI
298 * the archive of the old TestAPI
299 * the backup of the Mongo DB
301 TestAPI Authorization
302 ~~~~~~~~~~~~~~~~~~~~~
304 PUT/DELETE/POST operations of the TestAPI now require token based authorization. The token needs
305 to be added in the request using a header 'X-Auth-Token' for access to the database.
308 headers['X-Auth-Token']
310 The value of the header i.e the token can be accessed in the jenkins environment variable
311 *TestApiToken*. The token value is added as a masked password.
313 .. code-block:: python
315 headers['X-Auth-Token'] = os.environ.get('TestApiToken')
317 The above example is in Python. Token based authentication has been added so that only ci pods
318 jenkins job can have access to the database.
320 Please note that currently token authorization is implemented but is not yet enabled.
325 An automatic reporting page has been created in order to provide a
326 consistant view of the scenarios.
327 In this page, each scenario is evaluated according to test criteria.
328 The code for the automatic reporting is available at `[8]`_.
330 The results are collected from the centralized database every day and,
331 per scenario. A score is calculated based on the results from the last
332 10 days. This score is the addition of single test scores. Each test
333 case has a success criteria reflected in the criteria field from the
336 Considering an instance of a scenario os-odl_l2-nofeature-ha, the
337 scoring is the addition of the scores of all the runnable tests from the
338 categories (tiers healthcheck, smoke and features)
339 corresponding to this scenario.
342 +---------------------+---------+---------+---------+---------+
343 | Test | Apex | Compass | Fuel | Joid |
344 +=====================+=========+=========+=========+=========+
345 | vPing_ssh | X | X | X | X |
346 +---------------------+---------+---------+---------+---------+
347 | vPing_userdata | X | X | X | X |
348 +---------------------+---------+---------+---------+---------+
349 | tempest_smoke_serial| X | X | X | X |
350 +---------------------+---------+---------+---------+---------+
351 | rally_sanity | X | X | X | X |
352 +---------------------+---------+---------+---------+---------+
353 | odl | X | X | X | X |
354 +---------------------+---------+---------+---------+---------+
355 | promise | | | X | X |
356 +---------------------+---------+---------+---------+---------+
357 | doctor | X | | X | |
358 +---------------------+---------+---------+---------+---------+
359 | security_scan | X | | | |
360 +---------------------+---------+---------+---------+---------+
362 +---------------------+---------+---------+---------+---------+
363 | copper | X | | | X |
364 +---------------------+---------+---------+---------+---------+
365 src: colorado (see release note for the last matrix version)
367 All the testcases listed in the table are runnable on
368 os-odl_l2-nofeature scenarios.
369 If no result is available or if all the results are failed, the test
371 If it was succesfull at least once but not anymore during the 4 runs,
372 the case get 1 point (it worked once).
373 If at least 3 of the last 4 runs were successful, the case get 2 points.
374 If the last 4 runs of the test are successful, the test get 3 points.
376 In the example above, the target score for fuel/os-odl_l2-nofeature-ha
379 The scenario is validated per installer when we got 3 points for all
380 individual test cases (e.g 18/18).
381 Please note that complex or long duration tests are not considered for
382 the scoring. The success criteria are not always easy to define and may
383 require specific hardware configuration. These results however provide
384 a good level of trust on the scenario.
386 A web page is automatically generated every day to display the status.
387 This page can be found at `[9]`_. For the status, click on Status menu,
388 you may also get feedback for vims and tempest_smoke_serial test cases.
390 Any validated scenario is stored in a local file on the web server. In
391 fact as we are using a sliding windows to get results, it may happen
392 that a successful scenarios is no more run (because considered as
393 stable) and then the number of iterations (4 needed) would not be
394 sufficient to get the green status.
396 Please note that other test cases (e.g. sfc_odl, bgpvpn) need also
397 ODL configuration addons and as a consequence specific scenario.
398 There are not considered as runnable on the generic odl_l2 scenario.
403 Dashboard is used to provide a consistant view of the results collected
405 The results showed on the dashboard are post processed from the Database,
406 which only contains raw results.
408 In Brahmaputra, we created a basic dashboard.
409 Since Colorado, it was decided to adopt ELK framework. Mongo DB results
410 are extracted to feed Elasticsearch database (`[7]`_).
412 A script was developed to build elasticsearch data set. This
413 script can be found in `[16]`_.
415 For next versions, it was decided to integrated bitergia dashboard.
416 Bitergia already provides a dashboard for code and infrastructure.
417 A new Test tab will be added. The dataset will be built by consuming
428 The installation and configuration of the Functest docker image is
431 The procedure to start tests is described in `[2]`_
434 How can I contribute to Functest?
435 =================================
437 If you are already a contributor of any OPNFV project, you can
438 contribute to functest. If you are totally new to OPNFV, you must first
439 create your Linux Foundation account, then contact us in order to
440 declare you in the repository database.
442 We distinguish 2 levels of contributors:
444 * the standard contributor can push patch and vote +1/0/-1 on any Functest patch
445 * The commitor can vote -2/-1/0/+1/+2 and merge
447 Functest commitors are promoted by the Functest contributors.
450 Where can I find some help to start?
451 ====================================
453 This guide is made for you. You can also have a look at the project wiki
455 There are references on documentation, video tutorials, tips...
457 You can also directly contact us by mail with [Functest] prefix in the
458 title at opnfv-tech-discuss@lists.opnfv.org or on the IRC chan
462 What kind of testing do you do in Functest?
463 ===========================================
465 Functest is focusing on Functional testing. The results must be PASS or
466 FAIL. We do not deal with performance and/or qualification tests.
467 We consider OPNFV as a black box and execute our tests from the jumphost
468 according to Pharos reference technical architecture.
470 Upstream test suites are integrated (Rally/Tempest/ODL/ONOS,...).
471 If needed Functest may bootstrap temporarily testing activities if they
472 are identified but not covered yet by an existing testing project (e.g
473 security_scan before the creation of the security repository)
476 How test constraints are defined?
477 =================================
479 Test constraints are defined according to 2 paramaters:
481 * The scenario (DEPLOY_SCENARIO env variable)
482 * The installer (INSTALLER_TYPE env variable)
484 A scenario is a formal description of the system under test.
485 The rules to define a scenario are described in `[4]`_
487 These 2 constraints are considered to determinate if the test is runnable
488 or not (e.g. no need to run onos suite on odl scenario).
490 In the test declaration for CI, the test owner shall indicate these 2
491 constraints. The file testcases.yaml `[5]`_ must be patched in git to
492 include new test cases. A more elaborated system based on template is
493 planned for next releases
495 For each dependency, it is possible to define a regex::
498 criteria: 'success_rate == 100%'
500 Test suite from Promise project.
502 installer: '(fuel)|(joid)'
505 In the example above, it means that promise test will be runnable only
506 with joid or fuel installers on any scenario.
508 The vims criteria means any installer and exclude onos and odl with
512 criteria: 'status == "PASS"'
514 This test case deploys an OpenSource vIMS solution from Clearwater
515 using the Cloudify orchestrator. It also runs some signaling traffic.
518 scenario: '(ocl)|(nosdn)|^(os-odl)((?!bgpvpn).)*$'
521 How to write and check constaint regex?
522 =======================================
524 Regex are standard regex. You can have a look at `[11]`_
526 You can also easily test your regex via an online regex checker such as `[12]`_.
527 Put your scenario in the TEST STRING window (e.g. os-odl_l3-ovs-ha), put
528 your regex in the REGULAR EXPRESSION window, then you can test your rule.
531 How to know which test I can run?
532 =================================
534 You can use the API `[13]`_. The static declaration is in git `[5]`_
536 If you are in a Functest docker container (assuming that the
537 environement has been prepared): just use the CLI.
539 You can get the list per Test cases or by Tier::
541 # functest testcase list
550 tempest_full_parallel
557 ['vping_ssh', 'vping_userdata', 'tempest_smoke_serial', 'rally_sanity']
561 ['doctor', 'security_scan']
563 ['tempest_full_parallel', 'rally_full']
568 How to manually start Functest tests?
569 =====================================
571 Assuming that you are connected on the jumphost and that the system is
572 "Pharos compliant", i.e the technical architecture is compatible with
573 the one defined in the Pharos project::
575 # docker pull opnfv/functest:latest
576 # envs="-e INSTALLER_TYPE=fuel -e INSTALLER_IP=10.20.0.2 -e DEPLOY_SCENARIO=os-odl_l2-nofeature-ha -e CI_DEBUG=true"
577 # sudo docker run --privileged=true -id ${envs} opnfv/functest:latest /bin/bash
580 Then you must connect to the docker container and source the
583 # docker ps (copy the id)
584 # docker exec -ti <container_id> bash
588 You must first check if the environment is ready::
590 # functest env status
591 Functest environment ready to run tests.
594 If not ready, prepare the env by launching::
596 # functest env prepare
597 Functest environment ready to run tests.
599 Once the Functest env is ready, you can use the CLI to start tests.
601 You can run test cases per test case or per tier:
602 # functest testcase run <case name> or # functest tier run <tier name>
607 # functest testcase run tempest_smoke_serial
608 # functest tier run features
611 If you want to run all the tests you can type::
613 # functest testcase run all
616 If you want to run all the tiers (same at the end that running all the
617 test cases) you can type::
619 # functest tier run all
622 How to declare my tests in Functest?
623 ====================================
625 If you want to add new internal test cases, you can submit patch under
626 the testcases directory of Functest repository.
628 For feature test integration, the code can be kept into your own
629 repository. The Functest files to be modified are:
631 * functest/docker/Dockerfile: get your code in Functest container
632 * functest/ci/testcases.yaml: reference your test and its associated constraints
638 This file lists the repositories (internal or external) to be cloned in
639 the Functest container. You can also add external packages::
641 RUN git clone https://gerrit.opnfv.org/gerrit/<your project> ${REPOS_DIR}/<your project>
646 All the test cases that must be run from CI / CLI must be declared in
649 This file is used to get the constraints related to the test::
651 name: <my_super_test_case>
652 criteria: <not used yet in Colorado, could be > 'PASS', 'rate > 90%'
654 <the description of your super test suite>
656 installer: regex related to installer e.g. 'fuel', '(apex)||(joid)'
657 scenario: regex related to the scenario e.g. 'ovs*no-ha'
660 You must declare your test case in one of the category (tier).
662 If you are integrating test suites from a feature project, the default
663 category is **features**.
666 How to select my list of tests for CI?
667 ======================================
669 Functest can be run automatically from CI, a jenkins job is usually
670 called after an OPNFV fresh installation.
671 By default we try to run all the possible tests (see `[14]` called from
672 Functest jenkins job)::
674 cmd="python ${FUNCTEST_REPO_DIR}/ci/run_tests.py -t all ${flags}"
677 Each case can be configured as daily and/or weekly task.
678 Weekly tasks are used for long duration or experimental tests.
679 Daily tasks correspond to the minimum set of test suites to validate a scenario.
681 When executing run_tests.py, a check based on the jenkins build tag will
682 be considered to detect whether it is a daily and/or a weekly test.
684 in your CI you can customize the list of test you want to run by case or
685 by tier, just change the line::
687 cmd="python ${FUNCTEST_REPO_DIR}/ci/run_tests.py -t <whatever you want> ${flags}"
691 cmd="python ${FUNCTEST_REPO_DIR}/ci/run_tests.py -t healthcheck,smoke ${flags}"
693 This command will run all the test cases of the first 2 tiers, i.e.
694 healthcheck, connection_check, api_check, vping_ssh, vping_userdata,
695 snaps_somke, tempest_smoke_serial and rally_sanity.
698 How to push your results into the Test Database
699 ===============================================
701 The test database is used to collect test results. By default it is
702 enabled only for CI tests from Production CI pods.
704 The architecture and associated API is described in previous chapter.
705 If you want to push your results from CI, you just have to call the API
706 at the end of your script.
708 You can also reuse a python function defined in functest_utils.py::
710 def push_results_to_db(db_url, case_name, logger, pod_name,version, payload):
712 POST results to the Result target DB
714 url = db_url + "/results"
715 installer = get_installer_type(logger)
716 params = {"project_name": "functest", "case_name": case_name,
717 "pod_name": pod_name, "installer": installer,
718 "version": version, "details": payload}
720 headers = {'Content-Type': 'application/json'}
722 r = requests.post(url, data=json.dumps(params), headers=headers)
727 print "Error [push_results_to_db('%s', '%s', '%s', '%s', '%s')]:" \
728 % (db_url, case_name, pod_name, version, payload), e
732 Where can I find the documentation on the test API?
733 ===================================================
735 http://artifacts.opnfv.org/releng/docs/testapi.html
738 How to exclude Tempest case from default Tempest smoke suite?
739 =============================================================
741 Tempest default smoke suite deals with 165 test cases.
742 Since Colorado the success criteria is 100%, i.e. if 1 test is failed the
743 success criteria is not matched for the scenario.
745 It is necessary to exclude some test cases that are expected to fail due to
746 known upstream bugs (see release notes).
748 A file has been created for such operation: https://git.opnfv.org/cgit/functest/tree/functest/opnfv_tests/openstack/tempest/custom_tests/blacklist.txt.
750 It can be described as follows::
754 - os-odl_l2-bgpvpn-ha
755 - os-odl_l2-bgpvpn-noha
760 - tempest.api.compute.servers.test_create_server.ServersTestJSON.test_list_servers
761 - tempest.api.compute.servers.test_create_server.ServersTestJSON.test_verify_server_details
762 - tempest.api.compute.servers.test_create_server.ServersTestManualDisk.test_list_servers
763 - tempest.api.compute.servers.test_create_server.ServersTestManualDisk.test_verify_server_details
764 - tempest.api.compute.servers.test_server_actions.ServerActionsTestJSON.test_reboot_server_hard
765 - tempest.scenario.test_network_basic_ops.TestNetworkBasicOps.test_network_basic_ops
766 - tempest.scenario.test_server_basic_ops.TestServerBasicOps.test_server_basic_ops
767 - tempest.scenario.test_volume_boot_pattern.TestVolumeBootPattern.test_volume_boot_pattern
768 - tempest.scenario.test_volume_boot_pattern.TestVolumeBootPatternV2.test_volume_boot_pattern
770 Please note that each exclusion must be justified. the goal is not to exclude
771 test cases because they do not pass. Several scenarios reached the 100% criteria.
772 So it is expected in the patch submited to exclude the cases to indicate the
773 reasons of the exclusion.
776 How do I know the Functest status of a scenario?
777 ================================================
779 A Functest automatic reporting page is generated daily.
780 This page is dynamically created through a cron job and is based on the results
781 stored in the Test DB.
782 You can access this reporting page: http://testresults.opnfv.org/reporting
784 See https://wiki.opnfv.org/pages/viewpage.action?pageId=6828617 for details.
787 I have tests, to which category should I declare them?
788 ======================================================
790 CATEGORIES/TIERS description:
792 +----------------+-------------------------------------------------------------+
793 | healthcheck | Simple OpenStack healtcheck tests case that validates the |
794 | | basic operations in OpenStack |
795 +----------------+-------------------------------------------------------------+
796 | Smoke | Set of smoke test cases/suites to validate the most common |
797 | | OpenStack and SDN Controller operations |
798 +----------------+-------------------------------------------------------------+
799 | Features | Test cases that validate a specific feature on top of OPNFV.|
800 | | Those come from Feature projects and need a bit of support |
801 | | for integration |
802 +----------------+-------------------------------------------------------------+
803 | Components | Advanced Openstack tests: Full Tempest, Full Rally |
804 +----------------+-------------------------------------------------------------+
805 | Performance | Out of Functest Scope |
806 +----------------+-------------------------------------------------------------+
807 | VNF | Test cases related to deploy an open source VNF including |
808 | | an orchestrator |
809 +----------------+-------------------------------------------------------------+
811 The main ambiguity could be between features and VNF.
812 In fact sometimes you have to spawn VMs to demonstrate the capabilities of the
813 feature you introduced.
814 We recommend to declare your test in the feature category.
816 VNF category is really dedicated to test including:
818 * creation of resources
819 * deployement of an orchestrator/VNFM
820 * deployment of the VNF
824 The goal is not to study a particular feature on the infrastructure but to have
825 a whole end to end test of a VNF automatically deployed in CI.
826 Moreover VNF are run in weekly jobs (one a week), feature tests are in daily
827 jobs and use to get a scenario score.
832 Functest deals with internal and external testcases. Each testcase can generate
835 Since Colorado we introduce the possibility to push the logs to the artifact.
836 A new script (https://git.opnfv.org/releng/tree/utils/push-test-logs.sh) has
839 When called, and assuming that the POD is authorized to push the logs to
840 artifacts, the script will push all the results or logs locally stored under
841 /home/opnfv/functest/results/.
843 If the POD is not connected to CI, logs are not pushed.
844 But in both cases, logs are stored in /home/opnfv/functest/results in the
846 Projects are encouraged to push their logs here.
848 Since Colorado it is also easy for feature project to integrate this feature by
849 adding the log file as output_file parameter when calling execute_command from
850 functest_utils library
852 ret_val = functest_utils.execute_command(cmd, output_file=log_file)
855 How does Functest deal with VNF onboarding?
856 ===========================================
858 VNF onboarding has been introduced in Brahmaputra through the automation of a
859 clearwater vIMS deployed thanks to cloudify orchestrator.
861 This automation has been described at OpenStack summit Barcelona:
862 https://youtu.be/Jr4nG74glmY
864 The goal of Functest consists in testing OPNFV from a functional perspective:
865 the NFVI and/or the features developed in OPNFV. Feature test suites are
866 provided by the feature project. Functest just simplifies the integration of
867 the suite into the CI and gives a consolidated view of the tests per scenario.
869 Functest does not develop VNFs.
871 Functest does not test any MANO stack.
873 OPNFV projects dealing with VNF onboarding
874 ------------------------------------------
876 Testing VNF is not the main goal however it gives interesting and realistic
877 feedback on OPNFV as a Telco cloud.
879 Onboarding VNF also allows to test a full stack: orchestrator + VNF.
881 Functest is VNF and MANO stack agnostic.
883 An internship has been initiated to reference the Open Source VNF: Intern
884 Project Open Source VNF catalog
886 New projects dealing with orchestrators or VNFs are candidate for Danube.
888 The 2 projects dealing with orchestration are:
890 * orchestra (Openbaton)
893 The Models project address various goals for promoting availability and
894 convergence of information and/or data models related to NFV service/VNF
895 management, as being defined in standards (SDOs) and as developed in open
898 Functest VNF onboarding
899 -----------------------
901 In order to simplify VNF onboarding a new abstraction class has been developed
904 This class is based on vnf_base and can be described as follow:
906 +------------+ +--------------+
907 | test_base |------------>| vnf_base |
908 +------------+ +--------------+
910 |_ deploy_orchestrator (optional)
916 Several methods are declared in vnf_base:
919 * deploy_orchestrator
924 deploy_vnf and test_vnf are mandatory.
926 prepare will create a user and a project.
928 How to declare your orchestrator/VNF?
929 -------------------------------------
932 You must declare your testcase in the file <Functest repo>/functest/ci/testcases.yaml
936 You can precise some configuration parameters in config_functest.yaml
938 3) implement your test
940 Create your own VnfOnboarding file
942 you must create your entry point through a python clase as referenced in the
945 e.g. aaa => creation of the file <Functest repo>/functest/opnfv_tests/vnf/aaa/aaa.py
947 the class shall inherit vnf_base.
948 You must implement the methods deploy_vnf() and test_vnf() and may implement
949 deploy_orchestrator()
951 you can call the code from your repo (but need to add the repo in Functest if
956 So far we considered the test as PASS if vnf_deploy and test_vnf is PASS
957 (see example in aaa).
963 _`[1]`: http://artifacts.opnfv.org/functest/docs/configguide/index.html Functest configuration guide
965 _`[2]`: http://artifacts.opnfv.org/functest/docs/userguide/index.html functest user guide
967 _`[3]`: https://wiki.opnfv.org/opnfv_test_dashboard Brahmaputra dashboard
969 _`[4]`: https://wiki.opnfv.org/display/INF/CI+Scenario+Naming
971 _`[5]`: https://git.opnfv.org/cgit/functest/tree/ci/testcases.yaml
973 _`[6]`: https://git.opnfv.org/cgit/releng/tree/utils/test/result_collection_api
975 _`[7]`: https://git.opnfv.org/cgit/releng/tree/utils/test/scripts
977 _`[8]`: https://git.opnfv.org/cgit/releng/tree/utils/test/reporting/functest
979 _`[9]`: http://testresults.opnfv.org/reporting/
981 _`[10]`: https://wiki.opnfv.org/opnfv_functional_testing
983 _`[11]`: https://docs.python.org/2/howto/regex.html
985 _`[12]`: https://regex101.com/
987 _`[13]`: http://testresults.opnfv.org/test/api/v1/projects/functest/cases
989 _`[14]`: https://git.opnfv.org/cgit/releng/tree/jjb/functest/functest-daily.sh
991 _`[15]`: https://git.opnfv.org/cgit/releng/tree/utils/test/result_collection_api/README.rst
993 _`[16]`: https://git.opnfv.org/cgit/releng/tree/utils/test/scripts/mongo_to_elasticsearch.py
995 _`[17]`: http://artifacts.opnfv.org/releng/docs/testapi.html
997 OPNFV main site: http://www.opnfv.org
999 OPNFV functional test page: https://wiki.opnfv.org/opnfv_functional_testing
1001 IRC support chan: #opnfv-functest
1003 _`OpenRC`: http://docs.openstack.org/user-guide/common/cli_set_environment_variables_using_openstack_rc.html
1005 _`Rally installation procedure`: https://rally.readthedocs.org/en/latest/tutorial/step_0_installation.html
1007 _`config_functest.yaml` : https://git.opnfv.org/cgit/functest/tree/functest/ci/config_functest.yaml