+ digraph onap_top_chart {
+ rankdir="LR";
+ {
+ node [shape=folder]
+ oValues [label="values.yaml"]
+ oChart [label="Chart.yaml"]
+ dev [label="dev.yaml"]
+ prod [label="prod.yaml"]
+ crb [label="clusterrolebindings.yaml"]
+ secrets [label="secrets.yaml"]
+ }
+ {
+ node [style=dashed]
+ vCom [label="component"]
+ }
+
+ onap -> oValues
+ onap -> oChart
+ onap -> templates
+ onap -> resources
+ oValues -> vCom
+ resources -> environments
+ environments -> dev
+ environments -> prod
+ templates -> crb
+ templates -> secrets
+ }
+
+Within the `values.yaml` file at the `onap` level, one will find a set of
+boolean values that control which of the ONAP components get deployed as shown
+below:
+
+.. code-block:: yaml
+
+ aaf: # Application Authorization Framework
+ enabled: false
+ <...>
+ so: # Service Orchestrator
+ enabled: true
+
+By setting these flags a custom deployment can be created and used during
+deployment by using the `-f` Helm option as follows::
+
+ > helm install local/onap -name development -f dev.yaml
+
+Note that there are one or more example deployment files in the
+`onap/resources/environments/` directory. It is best practice to create a
+unique deployment file for each environment used to ensure consistent
+behaviour.
+
+To aid in the long term supportability of ONAP, a set of common charts have
+been created (and will be expanded in subsequent releases of ONAP) that can be
+used by any of the ONAP components by including the common component in its
+`requirements.yaml` file. The common components are arranged as follows:
+
+.. graphviz::
+
+ digraph onap_common_chart {
+ rankdir="LR";
+ {
+ node [shape=folder]
+ mValues [label="values.yaml"]
+ ccValues [label="values.yaml"]
+ comValues [label="values.yaml"]
+ comChart [label="Chart.yaml"]
+ ccChart [label="Chart.yaml"]
+ mChart [label="Chart.yaml"]
+
+ mReq [label="requirements.yaml"]
+ mService [label="service.yaml"]
+ mMap [label="configmap.yaml"]
+ ccName [label="_name.tpl"]
+ ccNS [label="_namespace.tpl"]
+ }
+ {
+ cCom [label="common"]
+ mTemp [label="templates"]
+ ccTemp [label="templates"]
+ }
+ {
+ more [label="...",style=dashed]
+ }
+
+ common -> comValues
+ common -> comChart
+ common -> cCom
+ common -> mysql
+ common -> more
+
+ cCom -> ccChart
+ cCom -> ccValues
+ cCom -> ccTemp
+ ccTemp -> ccName
+ ccTemp -> ccNS
+
+ mysql -> mValues
+ mysql -> mChart
+ mysql -> mReq
+ mysql -> mTemp
+ mTemp -> mService
+ mTemp -> mMap
+ }
+
+The common section of charts consists of a set of templates that assist with
+parameter substitution (`_name.tpl` and `_namespace.tpl`) and a set of charts
+for components used throughout ONAP. Initially `mysql` is in the common area
+but this will expand to include other databases like `mariadb-galera`,
+`postgres`, and `cassandra`. Other candidates for common components include
+`redis` and`kafka`. When the common components are used by other charts they
+are instantiated each time. In subsequent ONAP releases some of the common
+components could be a setup as services that are used by multiple ONAP
+components thus minimizing the deployment and operational costs.
+
+All of the ONAP components have charts that follow the pattern shown below:
+
+.. graphviz::
+
+ digraph onap_component_chart {
+ rankdir="LR";
+ {
+ node [shape=folder]
+ cValues [label="values.yaml"]
+ cChart [label="Chart.yaml"]
+ cService [label="service.yaml"]
+ cMap [label="configmap.yaml"]
+ cFiles [label="config file(s)"]
+ }
+ {
+ cCharts [label="charts"]
+ cTemp [label="templates"]
+ cRes [label="resources"]
+
+ }
+ {
+ sCom [label="component",style=dashed]
+ }
+
+ component -> cValues
+ component -> cChart
+ component -> cCharts
+ component -> cTemp
+ component -> cRes
+ cTemp -> cService
+ cTemp -> cMap
+ cRes -> config
+ config -> cFiles
+ cCharts -> sCom
+ }
+
+Note that the component charts may include a hierarchy of components and in
+themselves can be quite complex.
+
+Configuration of the components varies somewhat from component to component but
+generally follows the pattern of one or more `configmap.yaml` files which can
+directly provide configuration to the containers in addition to processing
+configuration files stored in the `config` directory. It is the responsibility
+of each ONAP component team to update these configuration files when changes
+are made to the project containers that impact configuration.
+
+The following section describes how the hierarchical ONAP configuration system
+is key to management of such a large system.
+
+Configuration Management
+========================
+
+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.
+
+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:
+
+.. code-block:: yaml
+
+ apiVersion: extensions/v1beta1
+ kind: Deployment
+ metadata:
+ name: mariadb
+ spec:
+ <...>
+ template:
+ <...>
+ spec:
+ hostname: mariadb
+ containers:
+ - args:
+ image: nexus3.onap.org:10001/mariadb:10.1.11
+ name: "mariadb"
+ env:
+ - name: MYSQL_ROOT_PASSWORD
+ value: password
+ - name: MARIADB_MAJOR
+ value: "10.1"
+ <...>
+ imagePullSecrets:
+ - name: onap-docker-registry-key
+
+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.
+
+.. code-block:: yaml
+
+ apiVersion: extensions/v1beta1
+ kind: Deployment
+ metadata:
+ name: mariadb
+ namespace: "{{ .Values.nsPrefix }}-mso"
+ spec:
+ <...>
+ template:
+ <...>
+ spec:
+ hostname: mariadb
+ containers:
+ - args:
+ image: {{ .Values.image.mariadb }}
+ imagePullPolicy: {{ .Values.pullPolicy }}
+ name: "mariadb"
+ env:
+ - name: MYSQL_ROOT_PASSWORD
+ value: password
+ - name: MARIADB_MAJOR
+ value: "10.1"
+ <...>
+ imagePullSecrets:
+ - name: "{{ .Values.nsPrefix }}-docker-registry-key"apiVersion: extensions/v1beta1
+ kind: Deployment
+ metadata:
+ name: mariadb
+ namespace: "{{ .Values.nsPrefix }}-mso"
+ spec:
+ <...>
+ template:
+ <...>
+ spec:
+ hostname: mariadb
+ containers:
+ - args:
+ image: {{ .Values.image.mariadb }}
+ imagePullPolicy: {{ .Values.pullPolicy }}
+ name: "mariadb"
+ env:
+ - name: MYSQL_ROOT_PASSWORD
+ value: password
+ - name: MARIADB_MAJOR
+ value: "10.1"
+ <...>
+ imagePullSecrets:
+ - name: "{{ .Values.nsPrefix }}-docker-registry-key"
+
+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:
+
+.. code-block:: yaml
+
+ nsPrefix: onap
+ pullPolicy: IfNotPresent
+ image:
+ readiness: oomk8s/readiness-check:2.0.0
+ mso: nexus3.onap.org:10001/openecomp/mso:1.0-STAGING-latest
+ mariadb: nexus3.onap.org:10001/mariadb:10.1.11
+
+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:
+
+.. code-block:: yaml
+
+ imagePullSecrets:
+ - name: "{{ .Values.nsPrefix | default "onap" }}-docker-registry-key"
+
+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
+------------------------------