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
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.
VOLTHA releases applications by use a release branch pattern. Releases are numbered as
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:
and the following release tags exist:
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:
- On the last release branch for the application are there any differences between the last release tag and the
HEADof the release branch
- Is the
HEADof the last release branch different from the
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.
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
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
image2018-2-13 11:11:16.png (image/png)
image2018-2-13 11:15:48.png (image/png)
image2018-2-13 11:32:12.png (image/png)
image2018-2-13 16:22:31.png (image/png)
image2018-2-13 16:27:55.png (image/png)
image2018-2-13 17:24:10.png (image/png)