There is a desire to have common config files for pod/hardware, build, deploy, and test:
Different teams work on creating a common definition for those configuration files. Pod-setup is done by the Pharos team, Build and Deploy are worked by Genesis, and Test is done by the different testing teams.
Having a view of how the different deployment tools approach system configuration should ease distilling a common approach. Below is a listing of existing approaches of the install tools as well as snapshots of the current discussion. Note: This wiki is a snapshot in time. Definition of these common files is still work in progress!
The following patches are used as starting points to finalize the common config files for each area mentioned:
Build: As JOID is script and charm based installation there is no need to have build process.
Config:
Deploy:
Proposal for Fuel: https://gerrit.opnfv.org/gerrit/#/c/3995/ - simple method to separate configuration for base fuel, plugins, PODs and deployment/test scenarios
Current approach by Fuel (exampe for LF lab, pod 1):
YAML files to use as input to Apex build/deploy:
yaml inputs are broken up into:
YAML files to use as input to Compass4nfv build/deploy:
yaml inputs are broken up into:
Ongoing discussion in the Genesis team on common build/deploy config files (patch does not reflect the latest discussions):
https://gerrit.opnfv.org/gerrit/#/c/3583/
Testing leverages a choice of mechanisms (per Morgan):
In jenkins we get some information (installer), we retrieve dynamically the controller, potentially the creds (on production labs) and we setup the test env accordingly (still lots of tests when all controllers will be available), we should also be able to get specific config (customized OVS for example) there is already some config elements, we should probably consolidate them.
As a user, assuming you installed the functest docker file, you can already select the testcases you want to run (either internal cases or, in the future, what we called companion test projects - feature projects associated with functest): See "./run_tests.sh -h":
Script to trigger the tests automatically. usage: bash run_tests.sh [--offline] [-h|--help] [-t <test_name>] where: -o|--offline optional offline mode (experimental) -h|--help show this help text -t|--test run specific set of tests <test_name> one or more of the following: vping,odl,rally,tempest. Separated by comma. examples: run_tests.sh run_tests.sh --test vping,odl run_tests.sh --offline -t tempest,rally
We do not have lots of controls for the moment…if a user indicate odl and if odl is not installed we will get 100% failed.
We did not develop a tool where user could select the testcases he would like to execute (we got the list yesterday…) ⇒ generate a config file for functest (or extension to any test project) ⇒ could be tested towards the possible combinations and indicate at the end for the all the tests you want to have the best option is config X (from installer A, with controller B and customization C, to be tested on Lab D) For the moment we collected the projects with testcases and track the testcases (http://213.77.62.197/test_projects, http://213.77.62.197/test_projects/functest/cases,…), it could be an improvement…
However in Functest except for the controller tests that are obviously specific, we try to be as agnostic as possible of the OPNFV black box and shall be able to run towards any System Under Test..