User Tools

Site Tools


Discussion Input: Configuration for Pod-layout/Build/Deploy/Test

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!

Common config files

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

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.


  • deployment.yaml – contains information on how MAAS / JUJU VM will be configured including the interfaces where DHCP will be running.
  • – 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.yaml – contains the feature which will get installed as part of deployment.
  • – script which will deploy the OPNFV on the control and compute hosts.

Example: Fuel installer configuration

Proposal for Fuel: - 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:

Example: Compass4nfv installer configuration

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

yaml inputs are broken up into:

POD configuration file example from Yardstick

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):

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 "./ -h":

Script to trigger the tests automatically.

    bash [--offline] [-h|--help] [-t <test_name>]

    -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: --test vping,odl --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 (,,…), 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

genesis/configuration-files-discussion.txt · Last modified: 2015/12/15 14:44 by Frank Brockners