Separate, but related

While the ONOS control plane applications associated with VOLTHA are often spoken about as a group they are in fact individual projects that evolve and release independently. There are, however, dependencies between the projects and these dependencies are important to understand as you work with the control plane application as they are required when determining release order and release dependency propagation. Figure 1 visually depicts the application dependencies.

Figure 1 - VOLTHA Control Plane Application Dependencies

When updating version information and releasing applications it is important to start with the config and sadis applications as these are the applications that have no other dependencies within VOLTHA. Basically, the changes should start at the top of the graph and work their way down in reverse order of the dependencies.

Release philosophy

VOLTHA releases applications by use a release branch pattern. Releases are numbered as X.Y.Z, where X represents the major release number, Y represents the minor release number, and Z represents the revision (bug fix) release number. For every minor release, X.Y, VOLTHA has a release branch named <<project>>-X.Y. For ever release VOLTHA has a tag on that release branch named X.Y.Z. For example, on the aaa application the following release branches exist:

$ git branch -a | sed -E -e 's/ *remotes\/opencord\///g' | grep -E '^aaa-[0-9]+\.[0-9]+'
aaa-1.2
aaa-1.3
aaa-1.4
aaa-1.5

and the following release tags exist:

$ git tag | grep -E -e '^[0-9]+\.[0-9]+\.[0-9]+'
1.0.0
1.2.0
1.3.0
1.4.0
1.5.0

NOTE: Because of development history there may be branches and tags on the VOLTHA control plane applications that are not related to their release as part of the VOLTHA project

Is a release required?

A key question to ask before you attempt to release any of the applications is to verify if a release is required. This involves typically two checks that need to be made:

1. On the last release branch for the application are there any differences between the last release tag and the HEAD of the release branch
2. Is the HEAD of the last release branch different from the HEAD of the master branch

Based on the answer to these questions the action that needs to be taken can be determined as depicted in Figure 2.

Figure 2 - Release Decision Matrix

How to determine what has changed

To determine what has changed to use the matrix in Figure 2, you can use git diff commands. Alternatively, you can download and run the script what_should_i_do.sh on each of the VOLTHA control plane applications. This script automates the git commands required to determine what has changed and the outputs the design matrix action. Two example executions of the script are shown below.

host:~/src/opencord/master/onos-apps/apps/aaa$ what_should_i_do.sh -d
RELEASE_BRANCH is aaa-1.5
RELEASE_TAG is 1.5.0
No differences on release branch aaa-1.5 between tag 1.5.0 and HEAD
No differences between release branch aaa-1.5 and HEAD on master
Do nothing

host:~/src/opencord/master/onos-apps/apps/igmpproxy$ what_should_i_do.sh -d
RELEASE_BRANCH is igmpproxy-1.1
RELEASE_TAG is 1.1.1
Differences found on release branch igmpproxy-1.1 between tag 1.1.1 and HEAD
Differences found between release branch igmpproxy-1.1 and HEAD on master
Create new release branch igmpproxy-1.2 and release tag 1.2.0

But, what do I do?

Now that we know what needs to be done, the question is how is it done. The steps that need to be taken depend on what needs to be done. In general, the steps are as follows:

Figure 3 - Application Release Process Flow

But really, how do I do all that?

There are some keys to being able to accomplishing a release of a control plane application including:

• permission in the gerrit system to create and push branches
• permission in the gerrit system to create and push tags
• permission in the gerrit system to merge commits
• permission to run jenkins jobs
• permission in the Nexus Repositoy (oss.sonatype.org) system to release versions of the OAR files

There are also some tools that can help, including a handy dandy verision updater that is a jenkins job: https://jenkins.opencord.org/job/onos-app-release/. This jenkins job allows the user to specify the application an version parameters and will create release tag on the specified branch and then update the version on the branch to a new version. To start the pipeline you will need to select Build with Parameters link on the onos-app-release Jenkins job.

Figure 4 - Jenkins Pipeline to Create Release Tag on Branch