+.. This work is licensed under a Creative Commons Attribution 4.0 International License.
+.. SPDX-License-Identifier: CC-BY-4.0
+
******************************
OPNFV FUNCTEST developer guide
******************************
Functest is a project dealing with functional testing.
Functest produces its own internal test cases but can also be considered
as a framework to support feature and VNF onboarding project testing.
-Functest developed a test API and defined a test collection framework
+Functest developed a TestAPI and defined a test collection framework
that can be used by any OPNFV project.
Therefore there are many ways to contribute to Functest. You can:
============================
The internal test cases in Danube are:
- * healthcheck
- * connection_check
+
* api_check
+ * cloudify_ims
+ * connection_check
* vping_ssh
* vping_userdata
* odl
- * snaps_smoke
- * tempest_smoke_serial
+ * rally_full
* rally_sanity
+ * snaps_health_check
* tempest_full_parallel
- * rally_full
- * cloudify_ims
+ * tempest_smoke_serial
By internal, we mean that this particular test cases have been
developped and/or integrated by functest contributors and the associated
code is hosted in the Functest repository.
-An internal case can be fully developped or a simple integration of
+An internal case can be fully developed or a simple integration of
upstream suites (e.g. Tempest/Rally developped in OpenStack are just
integrated in Functest).
The structure of this repository is detailed in `[1]`_.
repository, the internal test cases are:
* sdn: odl, onos
- * openstack: healthcheck, vping_ssh, vping_userdata, tempest_*, rally_*, connection_check, api_check, snaps_smoke
+ * openstack: api_check, connection_check, snaps_health_check, vping_ssh, vping_userdata, tempest_*, rally_*, snaps_smoke
* vnf: cloudify_ims
If you want to create a new test case you will have to create a new
The external test cases are:
- * promise
- * doctor
- * onos
+ * barometer
* bgpvpn
- * copper
- * security_scan
- * sfc-odl
- * sfc-onos
- * parser
+ * doctor
* domino
+ * odl-netvirt
+ * onos
+ * fds
* multisite
- * opera_ims
* orchestra_ims
+ * parser
+ * promise
+ * refstack_defcore
+ * security_scan
+ * snaps_smoke
+ * sfc-odl
+ * vyos_vrouter
The code to run these test cases may be directly in the repository of
the project. We have also a **features** sub directory under opnfv_tests
-directory that may be used (it can be usefull if you want to reuse
+directory that may be used (it can be useful if you want to reuse
Functest library).
Functest framework
Functest can be considered as a framework.
Functest is release as a docker file, including tools, scripts and a CLI
-to prepare the environement and run tests.
+to prepare the environment and run tests.
It simplifies the integration of external test suites in CI pipeline
and provide commodity tools to collect and display results.
Since Colorado, test categories also known as tiers have been created to
-group similar tests, provide consistant sub-lists and at the end optimize
+group similar tests, provide consistent sub-lists and at the end optimize
test duration for CI (see How To section).
The definition of the tiers has been agreed by the testing working group.
In order to harmonize test integration, 3 abstraction classes have been
introduced in Danube:
- * testcase_base: base for any test case
- * feature_base: abstraction for feature project
+ * testcase: base for any test case
+ * feature: abstraction for feature project
* vnf_base: abstraction for vnf onboarding
The goal is to unify the way to run test from Functest.
-feature_base and vnf_base inherit from testcase_base.
+feature and vnf_base inherit from testcase::
+-----------------------------------------+
| |
- | Testcase_base |
+ | TestCase |
| |
| - init() |
| - run() |
V V
+--------------------+ +--------------------------+
| | | |
- | feature_base | | vnf_base |
+ | feature | | vnf_base |
| | | |
| - prepare() | | - prepare() |
- | - post() | | - deploy_orchestrator() |
- | - parse_results() | | - deploy_vnf() |
- | | | - test_vnf() |
+ | - execute() | | - deploy_orchestrator() |
+ | - post() | | - deploy_vnf() |
+ | - parse_results() | | - test_vnf() |
| | | - clean() |
| | | - execute() |
| | | |
|-- config.py
|-- constants.py
|-- env.py
-|-- functest_constants.py
|-- functest_logger.py
|-- functest_utils.py
|-- openstack_clean.py
`-- openstack_utils.py
Note that for Openstack, keystone v3 is now deployed by default by compass,
-fuel and joid in Danube. All installers still support keysone v2 (deprecated in
+fuel and joid in Danube. All installers still support keystone v2 (deprecated in
next version).
Test collection framework
| |
+----------------------+
-Test API description
---------------------
-The Test API is used to declare pods, projects, test cases and test
+TestAPI description
+-------------------
+The TestAPI is used to declare pods, projects, test cases and test
results. Pods are the pods used to run the tests.
The results pushed in the database are related to pods, projects and
cases. If you try to push results of test done on non referenced pod,
An additional method dashboard has been added to post-process
the raw results in release Brahmaputra (deprecated in Colorado).
-The data model is very basic, 4 objects are created:
+The data model is very basic, 5 objects are created:
* Pods
* Projects
* Testcases
* Results
-
-Pods::
-
- {
- "id": <ID>,
- "details": <URL description of the POD>,
- "creation_date": "YYYY-MM-DD HH:MM:SS",
- "name": <The POD Name>,
- "mode": <metal or virtual>,
- "role": <ci-pod or community-pod or single-node>
- },
-
-Projects::
-
- {
- "id": <ID>,
- "name": <Name of the Project>,
- "creation_date": "YYYY-MM-DD HH:MM:SS",
- "description": <Short description>
- },
-
-Testcases::
-
- {
- "id": <ID>,
- "name":<Name of the test case>,
- "project_name":<Name of belonged project>,
- "creation_date": "YYYY-MM-DD HH:MM:SS",
- "description": <short description>,
- "url":<URL for longer description>
- },
-
-Results::
-
- {
- "_id": <ID>,
- "case_name": <Reference to the test case>,
- "project_name": <Reference to project>,
- "pod_name": <Reference to POD where the test was executed>,
- "installer": <Installer Apex or Compass or Fuel or Joid>,
- "version": <master or Colorado or Brahmaputra>,
- "start_date": "YYYY-MM-DD HH:MM:SS",
- "stop_date": "YYYY-MM-DD HH:MM:SS",
- "build_tag": <such as "jenkins-functest-fuel-baremetal-daily-master-108">,
- "scenario": <Scenario on which the test was executed>,
- "criteria": <PASS or FAILED>,
- "trust_indicator": {
- "current": 0,
- "histories": []
- }
- }
-
-The API can described as follows. For detailed information, please go to
-
- http://testresults.opnfv.org/test/swagger/spec.html
-
- Authentication: opnfv/api@opnfv
-
-Version:
-
- +--------+--------------------------+-----------------------------------------+
- | Method | Path | Description |
- +========+==========================+=========================================+
- | GET | /versions | Get all supported API versions |
- +--------+--------------------------+-----------------------------------------+
-
-
-Pods:
-
- +--------+----------------------------+-----------------------------------------+
- | Method | Path | Description |
- +========+============================+=========================================+
- | GET | /api/v1/pods | Get the list of declared Labs (PODs) |
- +--------+----------------------------+-----------------------------------------+
- | POST | /api/v1/pods | Declare a new POD |
- | | | Content-Type: application/json |
- | | | { |
- | | | "name": "pod_foo", |
- | | | "mode": "metal", |
- | | | "role": "ci-pod", |
- | | | "details": "it is a ci pod" |
- | | | } |
- +--------+----------------------------+-----------------------------------------+
- | GET | /api/v1/pods/{pod_name} | Get a declared POD |
- +--------+----------------------------+-----------------------------------------+
-
-Projects:
-
- +--------+----------------------------+-----------------------------------------+
- | Method | Path | Description |
- +========+============================+=========================================+
- | GET | /api/v1/projects | Get the list of declared projects |
- +--------+----------------------------+-----------------------------------------+
- | POST | /api/v1/projects | Declare a new test project |
- | | | Content-Type: application/json |
- | | | { |
- | | | "name": "project_foo", |
- | | | "description": "whatever you want" |
- | | | } |
- +--------+----------------------------+-----------------------------------------+
- | DELETE | /api/v1/projects/{project} | Delete a test project |
- +--------+----------------------------+-----------------------------------------+
- | GET | /api/v1/projects/{project} | Get details on a {project} |
- | | | |
- +--------+----------------------------+-----------------------------------------+
- | PUT | /api/v1/projects/{project} | Update a test project |
- | | | |
- | | | Content-Type: application/json |
- | | | { |
- | | | <the field(s) you want to modify> |
- | | | } |
- +--------+----------------------------+-----------------------------------------+
-
-
-Testcases:
-
- +--------+----------------------------+-----------------------------------------+
- | Method | Path | Description |
- +========+============================+=========================================+
- | GET | /api/v1/projects/{project}/| Get the list of testcases of {project} |
- | | cases | |
- +--------+----------------------------+-----------------------------------------+
- | POST | /api/v1/projects/{project}/| Add a new test case to {project} |
- | | cases | Content-Type: application/json |
- | | | { |
- | | | "name": "case_foo", |
- | | | "description": "whatever you want" |
- | | | "url": "whatever you want" |
- | | | } |
- +--------+----------------------------+-----------------------------------------+
- | DELETE | /api/v1/projects/{project}/| Delete a test case |
- | | cases/{case} | |
- +--------+----------------------------+-----------------------------------------+
- | GET | /api/v1/projects/{project}/| Get a declared test case |
- | | cases/{case} | |
- +--------+----------------------------+-----------------------------------------+
- | PUT | /api/v1/projects/{project}?| Modify a test case of {project} |
- | | cases/{case} | |
- | | | Content-Type: application/json |
- | | | { |
- | | | <the field(s) you want to modify> |
- | | | } |
- +--------+----------------------------+-----------------------------------------+
-
-Results:
-
- +--------+----------------------------+------------------------------------------+
- | Method | Path | Description |
- +========+============================+==========================================+
- | GET | /api/v1/results | Get all the test results |
- +--------+----------------------------+------------------------------------------+
- | POST | /api/v1/results | Add a new test results |
- | | | Content-Type: application/json |
- | | | { |
- | | | "project_name": "project_foo", |
- | | | "scenario": "odl-l2", |
- | | | "stop_date": "2016-05-28T14:42:58.384Z", |
- | | | "trust_indicator": 0.5, |
- | | | "case_name": "vPing", |
- | | | "build_tag": "", |
- | | | "version": "Colorado", |
- | | | "pod_name": "pod_foo", |
- | | | "criteria": "PASS", |
- | | | "installer": "fuel", |
- | | | "start_date": "2016-05-28T14:41:58.384Z",|
- | | | "details": <your results> |
- | | | } |
- +--------+----------------------------+------------------------------------------+
- | GET | /api/v1/results? | Get the test results of {case} |
- | | case={case} | |
- +--------+----------------------------+------------------------------------------+
- | GET | /api/v1/results? | Get the test results of build_tag |
- | | build_tag={tag} | {tag}. |
- +--------+----------------------------+------------------------------------------+
- | GET | /api/v1/results? | Get last {N} records of test results |
- | | last={N} | |
- +--------+----------------------------+------------------------------------------+
- | GET | /api/v1/results? | Get the test results of scenario |
- | | scenario={scenario} | {scenario}. |
- +--------+----------------------------+------------------------------------------+
- | GET | /api/v1/results? | Get the test results of trust_indicator |
- | | trust_indicator={ind} | {ind}. |
- +--------+----------------------------+------------------------------------------+
- | GET | /api/v1/results? | Get the test results of last days |
- | | period={period} | {period}. |
- +--------+----------------------------+------------------------------------------+
- | GET | /api/v1/results? | Get the test results of {project} |
- | | project={project} | |
- +--------+----------------------------+------------------------------------------+
- | GET | /api/v1/results? | Get the test results of version |
- | | version={version} | {version}. |
- +--------+----------------------------+------------------------------------------+
- | GET | /api/v1/results? | Get the test results of criteria |
- | | criteria={criteria} | {criteria}. |
- +--------+----------------------------+------------------------------------------+
- | GET | /api/v1/results? | get the results on pod {pod} |
- | | pod={pod} | |
- +--------+----------------------------+------------------------------------------+
- | GET | /api/v1/results? | Get the test results of installer {inst} |
- | | installer={inst} | |
- +--------+----------------------------+------------------------------------------+
- | GET | /api/v1/results? | Get the results according to combined |
- | | <query conditions> | query conditions supported above |
- +--------+----------------------------+------------------------------------------+
- | GET | /api/v1/results/{result_id}| Get the test result by result_id |
- +--------+----------------------------+------------------------------------------+
-
-Scenarios:
-
- +--------+----------------------------+-----------------------------------------+
- | Method | Path | Description |
- +========+============================+=========================================+
- | GET | /api/v1/scenarios | Get the list of declared scenarios |
- +--------+----------------------------+-----------------------------------------+
- | POST | /api/v1/scenario | Declare a new scenario |
- +--------+----------------------------+-----------------------------------------+
- | GET | /api/v1/scenario? | Get a declared scenario |
- | | <query conditions> | |
- +--------+----------------------------+-----------------------------------------+
-
+ * Scenarios
The code of the API is hosted in the releng repository `[6]`_.
The static documentation of the API can be found at `[17]`_.
-The test API has been dockerized and may be installed locally in your
+The TestAPI has been dockerized and may be installed locally in your
lab. See `[15]`_ for details.
-The deployment of the test API has been automated.
+The deployment of the TestAPI has been automated.
A jenkins job manages:
- * the unit tests of the test api
+ * the unit tests of the TestAPI
* the creation of a new docker file
- * the deployment of the new test api
- * the archive of the old test api
+ * the deployment of the new TestAPI
+ * the archive of the old TestAPI
* the backup of the Mongo DB
-Test API Authorization
-~~~~~~~~~~~~~~~~~~~~~~
+TestAPI Authorization
+~~~~~~~~~~~~~~~~~~~~~
-PUT/DELETE/POST operations of the testapi now require token based authorization. The token needs
+PUT/DELETE/POST operations of the TestAPI now require token based authorization. The token needs
to be added in the request using a header 'X-Auth-Token' for access to the database.
e.g::
===================
An automatic reporting page has been created in order to provide a
- consistant view of the scenarios.
+ consistent view of the scenarios.
In this page, each scenario is evaluated according to test criteria.
The code for the automatic reporting is available at `[8]`_.
+---------------------+---------+---------+---------+---------+
| parser | | | X | |
+---------------------+---------+---------+---------+---------+
- | copper | X | | | X |
- +---------------------+---------+---------+---------+---------+
+ src: colorado (see release note for the last matrix version)
All the testcases listed in the table are runnable on
os-odl_l2-nofeature scenarios.
If no result is available or if all the results are failed, the test
case get 0 point.
- If it was succesfull at least once but not anymore during the 4 runs,
+ If it was successful at least once but not anymore during the 4 runs,
the case get 1 point (it worked once).
If at least 3 of the last 4 runs were successful, the case get 2 points.
If the last 4 runs of the test are successful, the test get 3 points.
Dashboard
=========
-Dashboard is used to provide a consistant view of the results collected
+Dashboard is used to provide a consistent view of the results collected
in CI.
The results showed on the dashboard are post processed from the Database,
which only contains raw results.
For next versions, it was decided to integrated bitergia dashboard.
Bitergia already provides a dashboard for code and infrastructure.
A new Test tab will be added. The dataset will be built by consuming
-the test API.
+the TestAPI.
=======
security_scan before the creation of the security repository)
-How test constraints are defined?
+How are test constraints defined?
=================================
-Test constraints are defined according to 2 paramaters:
+Test constraints are defined according to 2 parameters:
* The scenario (DEPLOY_SCENARIO env variable)
* The installer (INSTALLER_TYPE env variable)
scenario: '(ocl)|(nosdn)|^(os-odl)((?!bgpvpn).)*$'
-How to write and check constaint regex?
+How to write and check constraint regex?
=======================================
Regex are standard regex. You can have a look at `[11]`_
You can also easily test your regex via an online regex checker such as `[12]`_.
Put your scenario in the TEST STRING window (e.g. os-odl_l3-ovs-ha), put
-your regex in the REGULAR EXPRESSION window, then you can test your rule
-.
+your regex in the REGULAR EXPRESSION window, then you can test your rule.
How to know which test I can run?
You can use the API `[13]`_. The static declaration is in git `[5]`_
If you are in a Functest docker container (assuming that the
-environement has been prepared): just use the CLI.
+environment has been prepared): just use the CLI.
You can get the list per Test cases or by Tier::
This command will run all the test cases of the first 2 tiers, i.e.
healthcheck, connection_check, api_check, vping_ssh, vping_userdata,
-snaps_somke, tempest_smoke_serial and rally_sanity.
+snaps_smoke, tempest_smoke_serial and rally_sanity.
How to push your results into the Test Database
return False
+Where can I find the documentation on the test API?
+===================================================
+
+http://artifacts.opnfv.org/releng/docs/testapi.html
+
+
+How to exclude Tempest case from default Tempest smoke suite?
+=============================================================
+
+Tempest default smoke suite deals with 165 test cases.
+Since Colorado the success criteria is 100%, i.e. if 1 test is failed the
+success criteria is not matched for the scenario.
+
+It is necessary to exclude some test cases that are expected to fail due to
+known upstream bugs (see release notes).
+
+A file has been created for such operation: https://git.opnfv.org/cgit/functest/tree/functest/opnfv_tests/openstack/tempest/custom_tests/blacklist.txt.
+
+It can be described as follows::
+
+ -
+ scenarios:
+ - os-odl_l2-bgpvpn-ha
+ - os-odl_l2-bgpvpn-noha
+ installers:
+ - fuel
+ - apex
+ tests:
+ - tempest.api.compute.servers.test_create_server.ServersTestJSON.test_list_servers
+ - tempest.api.compute.servers.test_create_server.ServersTestJSON.test_verify_server_details
+ - tempest.api.compute.servers.test_create_server.ServersTestManualDisk.test_list_servers
+ - tempest.api.compute.servers.test_create_server.ServersTestManualDisk.test_verify_server_details
+ - tempest.api.compute.servers.test_server_actions.ServerActionsTestJSON.test_reboot_server_hard
+ - tempest.scenario.test_network_basic_ops.TestNetworkBasicOps.test_network_basic_ops
+ - tempest.scenario.test_server_basic_ops.TestServerBasicOps.test_server_basic_ops
+ - tempest.scenario.test_volume_boot_pattern.TestVolumeBootPattern.test_volume_boot_pattern
+ - tempest.scenario.test_volume_boot_pattern.TestVolumeBootPatternV2.test_volume_boot_pattern
+
+Please note that each exclusion must be justified. the goal is not to exclude
+test cases because they do not pass. Several scenarios reached the 100% criteria.
+So it is expected in the patch submitted to exclude the cases to indicate the
+reasons of the exclusion.
+
+
+How do I know the Functest status of a scenario?
+================================================
+
+A Functest automatic reporting page is generated daily.
+This page is dynamically created through a cron job and is based on the results
+stored in the Test DB.
+You can access this reporting page: http://testresults.opnfv.org/reporting
+
+See https://wiki.opnfv.org/pages/viewpage.action?pageId=6828617 for details.
+
+
+I have tests, to which category should I declare them?
+======================================================
+
+CATEGORIES/TIERS description:
+
++----------------+-------------------------------------------------------------+
+| healthcheck | Simple OpenStack healthcheck tests case that validates the |
+| | basic operations in OpenStack |
++----------------+-------------------------------------------------------------+
+| Smoke | Set of smoke test cases/suites to validate the most common |
+| | OpenStack and SDN Controller operations |
++----------------+-------------------------------------------------------------+
+| Features | Test cases that validate a specific feature on top of OPNFV.|
+| | Those come from Feature projects and need a bit of support |
+| | for integration |
++----------------+-------------------------------------------------------------+
+| Components | Advanced OpenStack tests: Full Tempest, Full Rally |
++----------------+-------------------------------------------------------------+
+| Performance | Out of Functest Scope |
++----------------+-------------------------------------------------------------+
+| VNF | Test cases related to deploy an open source VNF including |
+| | an orchestrator |
++----------------+-------------------------------------------------------------+
+
+The main ambiguity could be between features and VNF.
+In fact sometimes you have to spawn VMs to demonstrate the capabilities of the
+feature you introduced.
+We recommend to declare your test in the feature category.
+
+VNF category is really dedicated to test including:
+
+ * creation of resources
+ * deployment of an orchestrator/VNFM
+ * deployment of the VNF
+ * test of the VNFM
+ * free resources
+
+The goal is not to study a particular feature on the infrastructure but to have
+a whole end to end test of a VNF automatically deployed in CI.
+Moreover VNF are run in weekly jobs (one a week), feature tests are in daily
+jobs and use to get a scenario score.
+
+Where are the logs?
+===================
+
+Functest deals with internal and external testcases. Each testcase can generate
+logs.
+
+Since Colorado we introduce the possibility to push the logs to the artifact.
+A new script (https://git.opnfv.org/releng/tree/utils/push-test-logs.sh) has
+been created for CI.
+
+When called, and assuming that the POD is authorized to push the logs to
+artifacts, the script will push all the results or logs locally stored under
+/home/opnfv/functest/results/.
+
+If the POD is not connected to CI, logs are not pushed.
+But in both cases, logs are stored in /home/opnfv/functest/results in the
+container.
+Projects are encouraged to push their logs here.
+
+Since Colorado it is also easy for feature project to integrate this feature by
+adding the log file as output_file parameter when calling execute_command from
+functest_utils library
+
+ ret_val = functest_utils.execute_command(cmd, output_file=log_file)
+
+
+How does Functest deal with VNF onboarding?
+===========================================
+
+VNF onboarding has been introduced in Brahmaputra through the automation of a
+clearwater vIMS deployed thanks to cloudify orchestrator.
+
+This automation has been described at OpenStack summit Barcelona:
+https://youtu.be/Jr4nG74glmY
+
+The goal of Functest consists in testing OPNFV from a functional perspective:
+the NFVI and/or the features developed in OPNFV. Feature test suites are
+provided by the feature project. Functest just simplifies the integration of
+the suite into the CI and gives a consolidated view of the tests per scenario.
+
+Functest does not develop VNFs.
+
+Functest does not test any MANO stack.
+
+OPNFV projects dealing with VNF onboarding
+------------------------------------------
+
+Testing VNF is not the main goal however it gives interesting and realistic
+feedback on OPNFV as a Telco cloud.
+
+Onboarding VNF also allows to test a full stack: orchestrator + VNF.
+
+Functest is VNF and MANO stack agnostic.
+
+An internship has been initiated to reference the Open Source VNF: Intern
+Project Open Source VNF catalog
+
+New projects dealing with orchestrators or VNFs are candidate for Danube.
+
+The 2 projects dealing with orchestration are:
+
+ * orchestra (Openbaton)
+ * opera (Open-O)
+
+The Models project address various goals for promoting availability and
+convergence of information and/or data models related to NFV service/VNF
+management, as being defined in standards (SDOs) and as developed in open
+source projects.
+
+Functest VNF onboarding
+-----------------------
+
+In order to simplify VNF onboarding a new abstraction class has been developed
+in Functest.
+
+This class is based on vnf_base and can be described as follow:
+
+ +------------+ +--------------+
+ | test_base |------------>| vnf_base |
+ +------------+ +--------------+
+ |_ prepare
+ |_ deploy_orchestrator (optional)
+ |_ deploy_vnf
+ |_ test_vnf
+ |_ clean
+
+
+Several methods are declared in vnf_base:
+
+ * prepare
+ * deploy_orchestrator
+ * deploy_vnf
+ * test_vnf
+ * clean
+
+deploy_vnf and test_vnf are mandatory.
+
+prepare will create a user and a project.
+
+How to declare your orchestrator/VNF?
+-------------------------------------
+1) test declaration
+
+You must declare your testcase in the file <Functest repo>/functest/ci/testcases.yaml
+
+2) configuration
+
+You can precise some configuration parameters in config_functest.yaml
+
+3) implement your test
+
+Create your own VnfOnboarding file
+
+you must create your entry point through a python class as referenced in the
+configuration file
+
+e.g. aaa => creation of the file <Functest repo>/functest/opnfv_tests/vnf/aaa/aaa.py
+
+the class shall inherit vnf_base.
+You must implement the methods deploy_vnf() and test_vnf() and may implement
+deploy_orchestrator()
+
+you can call the code from your repo (but need to add the repo in Functest if
+it is not the case)
+
+4) success criteria
+
+So far we considered the test as PASS if vnf_deploy and test_vnf is PASS
+(see example in aaa).
+
==========
References
==========
_`Rally installation procedure`: https://rally.readthedocs.org/en/latest/tutorial/step_0_installation.html
-_`config_functest.yaml` : https://git.opnfv.org/cgit/functest/tree/testcases/config_functest.yaml
+_`config_functest.yaml` : https://git.opnfv.org/cgit/functest/tree/functest/ci/config_functest.yaml
Code Review / functest.git / blobdiff