Introduction

ONAP is a large system composed of many components - each of which are complex systems in themselves - that needs to be deployed in a number of different ways.  For example, within a single operator's network there may be R&D deployments under active development, pre-production versions undergoing system testing and production systems that are operating live networks.  Each of these deployments will differ in significant ways, such as the version of the software images deployed.  In addition, there may be a number of application specific configuration differences, such as operating system environment variables.  The following describes how the Helm configuration management system is used within the OOM project to manage both ONAP infrastructure configuration as well as ONAP components configuration.

Table of Contents

ONAP Infrastructure Configuration

One of the artifacts that OOM/kubernetes uses to deploy ONAP components is the deployment specification, yet another yaml file.  Within these deployment specs are a number of parameters as shown in the following mariadb example:

deployment specification example

Note that within the deployment specification, one of the container arguments is the key/value pair image: nexus3.onap.org:10001/mariadb:10.1.11 which specifies the version of the mariadb software to deploy.  Although the deployment specifications greatly simplify deployment, maintenance of the deployment specifications themselves become problematic as software versions change over time or as different versions are required for different deployments.  For example, if the R&D team needs to deploy a newer version of mariadb than what is currently used in the production environment, they would need to clone the deployment specification and change this value.  Fortunately, this problem has been solved with the templating capabilities of Helm.   

The following example shows how the deployment specifications are modified to incorporate Helm templates such that key/value pairs can be defined outside of the deployment specifications and passed during instantiation of the component. 

deployment template example

This version of the deployment specification has gone through the process of templating values that are likely to change between deployments. Note that the image is now specified as: image: {{ .Values.image.mariadb }} instead of a string used previously.  During the deployment phase, Helm (actually the Helm sub-component Tiller) substitutes the {{ .. }} entries with a variable defined in a values.yaml file.  The content of this file is as follows:

values.yaml

Within the values.yaml file there is an image section with the key/value pair mariadb: nexus3.onap.org:10001/mariadb:10.1.11 which is the same value used in the non-templated version.  Once all of the substitutions are complete, the resulting deployment specification ready to be used by kubernetes.

Also note that in this example, the namespace key/value pair is specified in the values.yaml file.  This key/value pair will be global across the entire ONAP deployment and is therefore a prime example of where configuration hierarchy can be very useful.

When creating a deployment template consider the use of default values if appropriate.  Helm templating has built in support for DEFAULT values, here is an example:

Helm Template Defaults

The pipeline operator ("|") used here hints at that power of Helm templates in that much like an operating system command line the pipeline operator allow over 60 Helm functions to be embedded directly into the template (note that the Helm template language is a superset of the Go template language).  These functions include simple string operations like upper and more complex flow control operations like if/else.

ONAP Application Configuration

<..text..>

Configuration Parameters Mapping