There is a desire 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!

The following patches are used as starting points to finalize the common config files for each area mentioned:

• Common inventory file format:
  • https://gerrit.opnfv.org/gerrit/#/c/4079/ (AGREED as common format)

• Common network config file format:
  • https://gerrit.opnfv.org/gerrit/#/c/4095/1/common/fuel_3997_replica/labs/ericsson-1/pod-1/fuel/config/dea-pod-override.yaml (AGREED starting point for a common file)

• Common deployment scenario config file format:
  • https://gerrit.opnfv.org/gerrit/#/c/4201/1/common/config/deploy/example.yaml (AGREED starting point for a common file)

• List of key artifacts and their origin used for Brahmaputra builds:
  • https://gerrit.opnfv.org/gerrit/#/c/4585/ (documentation only)

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.

Proposal for Fuel: https://gerrit.opnfv.org/gerrit/#/c/3995/ - simple method to separate configuration for base fuel, plugins, PODs and deployment/test scenarios

• Fuel's current approach to locate artifacts is 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

• Configuration config file format (per component):
  • 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

Current approach by Fuel (exampe for LF lab, pod 1):

• dea.yaml – expresses the current deployment config
• dha.yaml – expresses the current hardware config

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

YAML files to use as input to Compass4nfv build/deploy:

yaml inputs are broken up into:

• build.yaml – build settings(tbd)
• deploy.yaml – deploy options
• network.yaml – network definition
• pod-config.yaml – pod baremetal/virtual information

https://git.opnfv.org/cgit/yardstick/tree/etc/yardstick/nodes/pod.yaml.sample

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..

• 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