Need to disable odl-l3 and enable neutron-l3-agent as part of the end-state of installation due to lack of support of IPv6 L3 routing in ODL Lithium

*.3, *.4

-

-

-

-

Use the OS+ODL environment to set up a service VM acting as an IPv6 vRouter. Because ODL Lithium doesn't support IPv6 L3 routing, the installed OS+ODL environment needs to use neutron-l3-agent instead of odl-l3

Test Scenarios for Brahmaputra

In Arno we just had two different deployment scenarios (one based on Fuel, one based on Foreman/Quickstack as installer). With Brahmaputra we’ll target a larger set. Given that we can think of more combinations than we have resources and time, we’ll need to nail those scenarios that we care about for Brahmaputra.

What is a scenario? A scenario is a particular deployment, i.e. the deployed composition of a set of components and their associated configuration. A scenario would ultimately be described through a set of configuration files (which is why we’re defining the common config files right now - https://wiki.opnfv.org/genesis/configuration-files-discussion#common_config_files). Apart from the description of the configuration, a scenario would come with its own documentation and eventually with its own test cases (e.g. to prove the specific functionality enabled by the scenario).

Which scenarios do we take on for Brahmaputra? The “starting point” scenarios are naturally those that we inherited from Arno SR1 – which is a bare-metal or virtual deployment of (Openstack, OpenDaylight, OVS, KVM) on either Centos or Ubuntu. But we obviously desire a lot of additional ones – especially to also reflect the various feature developments for Brahmaputra.

Call to action:

Definition: If you, your project or group-of-projects desire a scenario for Brahmaputra other than the ones we inherited from Arno SR1, please add your scenario to the table below. Arno SR1 scenarios are reflected as (A.1, C.1, F.1, J.1) and (A.2, C.2, F.2, J.2).

Ownership: When adding a scenario, please specify the owner of the scenario. It is the owner of a scenario who is responsible for creating the scenario (config files, debugging/maintenance, documentation, documentation of test results, specific tests etc.). Owners of a scenario are likely feature projects. Note that installers are typically not an owner (Arno was an exception), because installers only install features and components, but take no responsibility for the correct functioning of the features/components and the associated documentation. Also note that scenarios without owners are unlikely to happen…

Available Scenarios

Available scenarios mean that the scenarios listed on below page are currently running on CI.

Scenario and Jenkins Job Naming Scheme

It has been proposed to construct and align short scenario names in order to ease the Releng and Test Projects work to proceed with CI work and release verification.

An important aspect to point out is that even though short scenario names can give an idea regarding what a specific scenario is about, it is always important/necessary to look at and work with actual configuration files.

This naming convention is only valid for short scenario names and the details (config files, etc.) are handled within Genesis.

Both naming scenarios and Jenkins jobs have been touched upon during Daily Release Meeting on 2016-01-13 and there were no objections. See this link for minutes.

Scenario Naming

Short scenario names should follow the scheme below.

os-[controller]-[feature]-[mode]-[option]

Details of the fields are

os: mandatory

possible value: os

please note that this field is needed in order to select parent jobs to list and do blocking relations between them.

[controller]: mandatory

example values: nosdn, ocl, odl, onos

[feature]: mandatory

example values: nofeature, kvm, ovs

[mode]: mandatory

possible values: ha, noha

[option]: optional

used for the scenarios those do not fit into naming scheme.

optional field in the short scenario name should not be included if there is no optional scenario.

Examples are

os-nosdn-kvm-noha

os-odl_l2-nofeature-ha

os-onos-kvm_ovs-noha

Please note that the dashes (-) are the separator between fields.
Underscores (_) can be used for separating the values/words if a field contains more than one value (ie kvm_ovs).

This scenario naming scheme is currently in use/followed by compass, fuel, and joid.

Jenkins Job Structure

Jenkins jobs use Freestyle project type.

Please take a look at the examples from this or this link to see job structuring.

In this new job structure, there is 1 main job per scenario-pod-branch, controlling the executions of deploy, functest, and yardstick jobs. Main jobs are used for setting triggers, triggering jobs manually or automatically.

There is 1 job for each of the deploy, functest, and yardstick for pod-branch and these jobs take scenario short names from parent job and do what they are supposed to do with given scenario on the POD.

This job structure is currently in use/followed by compass, fuel and joid.

Jenkins Job Naming

Names of Jenkins Jobs require alignment as well in order to ease the triggering, configuration, management, and checking logs.

The jobs on Jenkins should be named according to below naming scheme.

Parent/Main Jobs: [installer]-[scenario]-[pod]-[loop]-[branch]

[installer]: apex, compass, fuel, joid

[scenario]: only the scenario names that fit into scenario naming scheme above.

[pod]: all the PODs that are assigned to specific installer and currently connected to Jenkins.

[loop]: daily

[branch]: master or brahmaputra

Deploy Jobs: [installer]-deploy-[pod]-[loop]-[branch]

[installer]: apex, compass, fuel, joid

[pod]: all the PODs that are assigned to specific installer and currently connected to Jenkins.

[loop]: daily

[branch]: master or brahmaputra

Test Jobs: [testproject]-[installer]-[pod]-[loop]-[branch]

[testproject]: functest, yardstick, bottlenecks, qtip

[installer]: apex, compass, fuel, joid

[pod]: all the PODs that are assigned to specific installer and currently connected to Jenkins.

This Jenkins Job naming scheme is currently in use/followed by compass, fuel and joid.

Brahmaputra Testing using non-CI production PODs

The PODs dedicated for CI production activities for Brahmaputra release are to be used for stable and latest release verification, including testing using Functest and Yardstick. Those PODs are fully allocated in daily basis for these activites.

In order to cover verification for all the testing frameworks delivering in Brahmaputra, it is necessary to use other OPNFV PODs, connected to CI, but not assigned to CI production.