There is a need to have common config files for pod/hardware, build, deploy, and test:

• Pod-setup (general description of the hardware setup of the POD used for a deployment)
• Build (description of the components used for a build – this will include pointers to the artifacts that a build will comprise, e.g. a pointer to the SDN controller)
• Deploy (description of how components would be configured, e.g. in ODL terms, this could be the set of features you want installed in karaf).
• Test (description of what tests within which testframeworks would be run)

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!

• Common artifacts locator file format (mostly for build):
  • https://gerrit.opnfv.org/gerrit/#/c/4375/ * Fuel's current approach (distributed in make files - look for the REPO= definition). Reason being that each collaboration project is responsible for their plug-in builder fragment and up-stream definition - see instructions here: https://wiki.opnfv.org/fuel_opnfv_integrated-project-guidelines_makefile * https://git.opnfv.org/cgit/fuel/tree/build/f_isoroot/f_odlpluginbuild/Makefile * https://git.opnfv.org/cgit/fuel/tree/build/f_isoroot/f_ovs-nsh-dpdk-pluginbuild/config.mk * https://git.opnfv.org/cgit/fuel/tree/build/f_isoroot/f_qemupluginbuild/config.mk * https://git.opnfv.org/cgit/fuel/tree/build/f_isoroot/f_onosfwpluginbuild/config.mk * Common inventory file format: * https://gerrit.opnfv.org/gerrit/#/c/4079/ (AGREED as common format) * https://git.opnfv.org/cgit/yardstick/tree/etc/yardstick/nodes/pod.yaml.sample * https://gerrit.opnfv.org/gerrit/#/c/4095/1/common/fuel_3997_replica/labs/ericsson-1/pod-1/fuel/config/dha.yaml * https://gerrit.opnfv.org/gerrit/#/c/4057/3/config/pod-config.yml * Common network config file format: * https://gerrit.opnfv.org/gerrit/#/c/4201/1/common/config/deploy/example.yaml * https://gerrit.opnfv.org/gerrit/#/c/4095/1/common/fuel_3997_replica/labs/ericsson-1/pod-1/fuel/config/dea-pod-override.yaml * https://gerrit.opnfv.org/gerrit/#/c/4057/3/config/network.yml * Common deployment scenario config file format: * https://gerrit.opnfv.org/gerrit/#/c/4201/1/common/config/deploy/example.yaml * https://gerrit.opnfv.org/gerrit/#/c/4095/1/common/fuel_3997_replica/installers/fuel/dea_base.yaml * https://gerrit.opnfv.org/gerrit/#/c/4057/3/config/deploy.yml * Common component configuration config file format (specific configuration for components such as ODL as SDN Controller or ONOS as SDN Controller) - could potentially be merged with the common deployment scenario config: * https://gerrit.opnfv.org/gerrit/#/c/4095/1/common/fuel_3997_replica/installers/fuel/plugins/fuel-ocl_0.0.1.yaml * https://gerrit.opnfv.org/gerrit/#/c/4095/1/common/fuel_3997_replica/installers/fuel/plugins/fuel-odl_0.0.1.yaml —- ====== Examples of installer configuration files ====== ==== Example: JOID installer configuration ==== Build: As JOID is script and charm based installation there is no need to have build process. Config:
    * deployment.yaml – contains information on how MAAS / JUJU VM will be configured including the interfaces where DHCP will be running. * interfaces.host – contains the network config of compute and control nodes. * lxc-add-more-interfaces – contains the config for containers installed on the control nodes for various services. Deploy:
    * deploy.yaml – contains the feature which will get installed as part of deployment. * deploy.sh – script which will deploy the OPNFV on the control and compute hosts. ==== Example: Fuel installer configuration ==== 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): * dea.yaml – expresses the current deployment config * dha.yaml – expresses the current hardware config ==== Example: APEX installer configuration ==== YAML files to use as input to Apex build/deploy: yaml inputs are broken up into: * build_settings.yaml – build settings * deploy_settings.yaml – deploy options * network-environment-example.yaml – network definition * pod_example_settings.yaml – pod baremetal information ==== POD configuration file example from Yardstick ==== https://git.opnfv.org/cgit/yardstick/tree/etc/yardstick/nodes/pod.yaml.sample ==== Strawman for Build/Deploy in Genesis ==== 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/ —- ====== Approach to test configuration ====== 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": <code> 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 </code> 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.. ====== Additional information: CI resources for Brahmaputra ====== * Brahmaputra CI process and resource needs: https://wiki.opnfv.org/octopus/brahmaputra_ci_process * Lab resources for Release B https://wiki.opnfv.org/pharos_rls_b_labs * Allocation and status of production CI resources * List of resources that are connected to OPNFV Jenkins … https://wiki.opnfv.org/pharos/hw_resource_allocation * Testing status snapshot https://wiki.opnfv.org/brahmaputra_testing_page * Configurations of installers auto-deployed and tested today * Test project lab needs and installer coverage