[GLOBAL] Migrate to helm v3
[oom.git] / docs / oom_developer_guide.rst
index c9aa629..05cdca1 100644 (file)
@@ -1,13 +1,14 @@
-.. This work is licensed under a Creative Commons Attribution 4.0 International License.
+.. This work is licensed under a Creative Commons Attribution 4.0
+.. International License.
 .. http://creativecommons.org/licenses/by/4.0
 .. http://creativecommons.org/licenses/by/4.0
-.. Copyright 2018 Amdocs, Bell Canada
+.. Copyright 2018-2020 Amdocs, Bell Canada, Orange, Samsung
 
 .. Links
 .. _Helm: https://docs.helm.sh/
 .. _Helm Charts: https://github.com/kubernetes/charts
 .. _Kubernetes: https://Kubernetes.io/
 .. _Docker: https://www.docker.com/
 
 .. Links
 .. _Helm: https://docs.helm.sh/
 .. _Helm Charts: https://github.com/kubernetes/charts
 .. _Kubernetes: https://Kubernetes.io/
 .. _Docker: https://www.docker.com/
-.. _Nexus: https://nexus.onap.org/#welcome
+.. _Nexus: https://nexus.onap.org/
 .. _AWS Elastic Block Store: https://aws.amazon.com/ebs/
 .. _Azure File: https://docs.microsoft.com/en-us/azure/storage/files/storage-files-introduction
 .. _GCE Persistent Disk: https://cloud.google.com/compute/docs/disks/
 .. _AWS Elastic Block Store: https://aws.amazon.com/ebs/
 .. _Azure File: https://docs.microsoft.com/en-us/azure/storage/files/storage-files-introduction
 .. _GCE Persistent Disk: https://cloud.google.com/compute/docs/disks/
@@ -79,158 +80,122 @@ have been created following the guidelines provided.
 
 The top level of the ONAP charts is shown below:
 
 
 The top level of the ONAP charts is shown below:
 
-.. graphviz::
+.. code-block:: bash
+
+  common
+  ├── cassandra
+  │   ├── Chart.yaml
+  │   ├── resources
+  │   │   ├── config
+  │   │   │   └── docker-entrypoint.sh
+  │   │   ├── exec.py
+  │   │   └── restore.sh
+  │   ├── templates
+  │   │   ├── backup
+  │   │   │   ├── configmap.yaml
+  │   │   │   ├── cronjob.yaml
+  │   │   │   ├── pv.yaml
+  │   │   │   └── pvc.yaml
+  │   │   ├── configmap.yaml
+  │   │   ├── pv.yaml
+  │   │   ├── service.yaml
+  │   │   └── statefulset.yaml
+  │   └── values.yaml
+  ├── common
+  │   ├── Chart.yaml
+  │   ├── templates
+  │   │   ├── _createPassword.tpl
+  │   │   ├── _ingress.tpl
+  │   │   ├── _labels.tpl
+  │   │   ├── _mariadb.tpl
+  │   │   ├── _name.tpl
+  │   │   ├── _namespace.tpl
+  │   │   ├── _repository.tpl
+  │   │   ├── _resources.tpl
+  │   │   ├── _secret.yaml
+  │   │   ├── _service.tpl
+  │   │   ├── _storage.tpl
+  │   │   └── _tplValue.tpl
+  │   └── values.yaml
+  ├── ...
+  └── postgres-legacy
+      ├── Chart.yaml
+      ├── charts
+      └── configs
 
 
-   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"]
-      }
+The common section of charts consists of a set of templates that assist with
+parameter substitution (`_name.tpl`, `_namespace.tpl` and others) and a set of
+charts for components used throughout ONAP.  When the common components are used
+by other charts they are instantiated each time or we can deploy a shared
+instances for several components.
 
 
-      onap         -> oValues
-      onap         -> oChart
-      onap         -> templates
-      onap         -> resources
-      oValues      -> vCom
-      resources    -> environments
-      environments -> dev
-      environments -> prod
-      templates    -> crb
-      templates    -> secrets
-   }
+All of the ONAP components have charts that follow the pattern shown below:
 
 
-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:: bash
+
+  name-of-my-component
+  ├── Chart.yaml
+  ├── component
+  │   └── subcomponent-folder
+  ├── charts
+  │   └── subchart-folder
+  ├── resources
+  │   ├── folder1
+  │   │   ├── file1
+  │   │   └── file2
+  │   └── folder1
+  │       ├── file3
+  │       └── folder3
+  │           └── file4
+  ├── templates
+  │   ├── NOTES.txt
+  │   ├── configmap.yaml
+  │   ├── deployment.yaml
+  │   ├── ingress.yaml
+  │   ├── job.yaml
+  │   ├── secrets.yaml
+  │   └── service.yaml
+  └── values.yaml
+
+Note that the component charts / components may include a hierarchy of sub
+components and in themselves can be quite complex.
+
+You can use either `charts` or `components` folder for your subcomponents.
+`charts` folder means that the subcomponent will always been deployed.
+
+`components` folders means we can choose if we want to deploy the
+subcomponent.
+
+This choice is done in root `values.yaml`:
 
 .. code-block:: yaml
 
 
 .. 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:
+  ---
+  global:
+    key: value
 
 
-.. 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"]
+  component1:
+    enabled: true
+  component2:
+    enabled: true
 
 
-      }
-      {
-         sCom       [label="component",style=dashed]
-      }
+Then in `Chart.yaml` dependencies section, you'll use these values:
 
 
-      component -> cValues
-      component -> cChart
-      component -> cCharts
-      component -> cTemp
-      component -> cRes
-      cTemp     -> cService
-      cTemp     -> cMap
-      cRes      -> config
-      config    -> cFiles
-      cCharts   -> sCom
-   }
+.. code-block:: yaml
 
 
-Note that the component charts may include a hierarchy of components and in
-themselves can be quite complex.
+  ---
+  dependencies:
+    - name: common
+      version: ~x.y-0
+      repository: '@local'
+    - name: component1
+      version: ~x.y-0
+      repository: 'file://components/component1'
+      condition: component1.enabled
+    - name: component2
+      version: ~x.y-0
+      repository: 'file://components/component2'
+      condition: component2.enabled
 
 Configuration of the components varies somewhat from component to component but
 generally follows the pattern of one or more `configmap.yaml` files which can
 
 Configuration of the components varies somewhat from component to component but
 generally follows the pattern of one or more `configmap.yaml` files which can
@@ -239,8 +204,8 @@ 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.
 
 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.  
+The following section describes how the hierarchical ONAP configuration system
+is key to management of such a large system.
 
 Configuration Management
 ========================
 
 Configuration Management
 ========================
@@ -259,126 +224,134 @@ 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
 
 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:
+are a number of parameters as shown in the following example:
 
 .. code-block:: yaml
 
 
 .. code-block:: yaml
 
-  apiVersion: extensions/v1beta1
-  kind: Deployment
+  apiVersion: apps/v1
+  kind: StatefulSet
   metadata:
   metadata:
-    name: mariadb
+    labels:
+      app.kubernetes.io/name: zookeeper
+      helm.sh/chart: zookeeper
+      app.kubernetes.io/component: server
+      app.kubernetes.io/managed-by: Tiller
+      app.kubernetes.io/instance: onap-oof
+    name: onap-oof-zookeeper
+    namespace: onap
   spec:
   spec:
-     <...>
+    <...>
+    replicas: 3
+    selector:
+      matchLabels:
+        app.kubernetes.io/name: zookeeper
+        app.kubernetes.io/component: server
+        app.kubernetes.io/instance: onap-oof
+    serviceName: onap-oof-zookeeper-headless
     template:
     template:
-      <...>
+      metadata:
+        labels:
+          app.kubernetes.io/name: zookeeper
+          helm.sh/chart: zookeeper
+          app.kubernetes.io/component: server
+          app.kubernetes.io/managed-by: Tiller
+          app.kubernetes.io/instance: onap-oof
       spec:
       spec:
-        hostname: mariadb
+        <...>
+        affinity:
         containers:
         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"
+        - name: zookeeper
           <...>
           <...>
-        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
+          image: gcr.io/google_samples/k8szk:v3
+          imagePullPolicy: Always
+          <...>
+          ports:
+          - containerPort: 2181
+            name: client
+            protocol: TCP
+          - containerPort: 3888
+            name: election
+            protocol: TCP
+          - containerPort: 2888
+            name: server
+            protocol: TCP
+          <...>
+
+Note that within the statefulset specification, one of the container arguments
+is the key/value pair image: gcr.io/google_samples/k8szk:v3 which
+specifies the version of the zookeeper software to deploy.  Although the
+statefulset specifications greatly simplify statefulset, maintenance of the
+statefulset specifications themselves become problematic as software versions
 change over time or as different versions are required for different
 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
+statefulsets.  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
 mariadb than what is currently used in the production environment, they would
-need to clone the deployment specification and change this value.  Fortunately,
+need to clone the statefulset specification and change this value.  Fortunately,
 this problem has been solved with the templating capabilities of Helm.
 
 this problem has been solved with the templating capabilities of Helm.
 
-The following example shows how the deployment specifications are modified to
+The following example shows how the statefulset specifications are modified to
 incorporate Helm templates such that key/value pairs can be defined outside of
 incorporate Helm templates such that key/value pairs can be defined outside of
-the deployment specifications and passed during instantiation of the component.
+the statefulset specifications and passed during instantiation of the component.
 
 .. code-block:: yaml
 
 
 .. code-block:: yaml
 
-  apiVersion: extensions/v1beta1
-  kind: Deployment
+  apiVersion: apps/v1
+  kind: StatefulSet
   metadata:
   metadata:
-    name: mariadb
-    namespace: "{{ .Values.nsPrefix }}-mso"
+    name: {{ include "common.fullname" . }}
+    namespace: {{ include "common.namespace" . }}
+    labels: {{- include "common.labels" . | nindent 4 }}
   spec:
   spec:
+    replicas: {{ .Values.replicaCount }}
+    selector:
+      matchLabels: {{- include "common.matchLabels" . | nindent 6 }}
+    # serviceName is only needed for StatefulSet
+    # put the postfix part only if you have add a postfix on the service name
+    serviceName: {{ include "common.servicename" . }}-{{ .Values.service.postfix }}
     <...>
     template:
     <...>
     template:
-      <...>
+      metadata:
+        labels: {{- include "common.labels" . | nindent 8 }}
+        annotations: {{- include "common.tplValue" (dict "value" .Values.podAnnotations "context" $) | nindent 8 }}
+        name: {{ include "common.name" . }}
       spec:
       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:
         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
+          - name: {{ include "common.name" . }}
+            image: {{ .Values.image }}
+            imagePullPolicy: {{ .Values.global.pullPolicy | default .Values.pullPolicy }}
+            ports:
+            {{- range $index, $port := .Values.service.ports }}
+              - containerPort: {{ $port.port }}
+                name: {{ $port.name }}
+            {{- end }}
+            {{- range $index, $port := .Values.service.headlessPorts }}
+              - containerPort: {{ $port.port }}
+                name: {{ $port.name }}
+            {{- end }}
+            <...>
+
+This version of the statefulset specification has gone through the process of
+templating values that are likely to change between statefulsets. Note that the
+image is now specified as: image: {{ .Values.image }} instead of a
+string used previously.  During the statefulset 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
 
 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:1.0.0
-    mso: nexus3.onap.org:10001/openecomp/mso:1.0-STAGING-latest
-    mariadb: nexus3.onap.org:10001/mariadb:10.1.11
+  <...>
+  image: gcr.io/google_samples/k8szk:v3
+  replicaCount: 3
+  <...>
 
 
-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.
+Within the values.yaml file there is an image key with the value
+`gcr.io/google_samples/k8szk:v3` which is the same value used in
+the non-templated version.  Once all of the substitutions are complete, the
+resulting statefulset specification ready to be used by Kubernetes.
 
 
-When creating a deployment template consider the use of default values if
-appropriate.  Helm templating has built in support for DEFAULT values, here is
+When creating a 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
 an example:
 
 .. code-block:: yaml
@@ -393,6 +366,230 @@ 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.
 
 functions include simple string operations like upper and more complex flow
 control operations like if/else.
 
+OOM is mainly helm templating. In order to have consistent deployment of the
+different components of ONAP, some rules must be followed.
+
+Templates are provided in order to create Kubernetes resources (Secrets,
+Ingress, Services, ...) or part of Kubernetes resources (names, labels,
+resources requests and limits, ...).
+
+a full list and simple description is done in
+`kubernetes/common/common/documentation.rst`.
+
+Service template
+----------------
+
+In order to create a Service for a component, you have to create a file (with
+`service` in the name.
+For normal service, just put the following line:
+
+.. code-block:: yaml
+
+  {{ include "common.service" . }}
+
+For headless service, the line to put is the following:
+
+.. code-block:: yaml
+
+  {{ include "common.headlessService" . }}
+
+The configuration of the service is done in component `values.yaml`:
+
+.. code-block:: yaml
+
+  service:
+   name: NAME-OF-THE-SERVICE
+   postfix: MY-POSTFIX
+   type: NodePort
+   annotations:
+     someAnnotationsKey: value
+   ports:
+   - name: tcp-MyPort
+     port: 5432
+     nodePort: 88
+   - name: http-api
+     port: 8080
+     nodePort: 89
+   - name: https-api
+     port: 9443
+     nodePort: 90
+
+`annotations` and `postfix` keys are optional.
+if `service.type` is `NodePort`, then you have to give `nodePort` value for your
+service ports (which is the end of the computed nodePort, see example).
+
+It would render the following Service Resource (for a component named
+`name-of-my-component`, with version `x.y.z`, helm deployment name
+`my-deployment` and `global.nodePortPrefix` `302`):
+
+.. code-block:: yaml
+
+  apiVersion: v1
+  kind: Service
+  metadata:
+    annotations:
+      someAnnotationsKey: value
+    name: NAME-OF-THE-SERVICE-MY-POSTFIX
+    labels:
+      app.kubernetes.io/name: name-of-my-component
+      helm.sh/chart: name-of-my-component-x.y.z
+      app.kubernetes.io/instance: my-deployment-name-of-my-component
+      app.kubernetes.io/managed-by: Tiller
+  spec:
+    ports:
+      - port: 5432
+        targetPort: tcp-MyPort
+        nodePort: 30288
+      - port: 8080
+        targetPort: http-api
+        nodePort: 30289
+      - port: 9443
+        targetPort: https-api
+        nodePort: 30290
+    selector:
+      app.kubernetes.io/name: name-of-my-component
+      app.kubernetes.io/instance:  my-deployment-name-of-my-component
+    type: NodePort
+
+In the deployment or statefulSet file, you needs to set the good labels in
+order for the service to match the pods.
+
+here's an example to be sure it matches (for a statefulSet):
+
+.. code-block:: yaml
+
+  apiVersion: apps/v1
+  kind: StatefulSet
+  metadata:
+    name: {{ include "common.fullname" . }}
+    namespace: {{ include "common.namespace" . }}
+    labels: {{- include "common.labels" . | nindent 4 }}
+  spec:
+    selector:
+      matchLabels: {{- include "common.matchLabels" . | nindent 6 }}
+    # serviceName is only needed for StatefulSet
+    # put the postfix part only if you have add a postfix on the service name
+    serviceName: {{ include "common.servicename" . }}-{{ .Values.service.postfix }}
+    <...>
+    template:
+      metadata:
+        labels: {{- include "common.labels" . | nindent 8 }}
+        annotations: {{- include "common.tplValue" (dict "value" .Values.podAnnotations "context" $) | nindent 8 }}
+        name: {{ include "common.name" . }}
+      spec:
+       <...>
+       containers:
+         - name: {{ include "common.name" . }}
+           ports:
+           {{- range $index, $port := .Values.service.ports }}
+           - containerPort: {{ $port.port }}
+             name: {{ $port.name }}
+           {{- end }}
+           {{- range $index, $port := .Values.service.headlessPorts }}
+           - containerPort: {{ $port.port }}
+             name: {{ $port.name }}
+           {{- end }}
+           <...>
+
+The configuration of the service is done in component `values.yaml`:
+
+.. code-block:: yaml
+
+  service:
+   name: NAME-OF-THE-SERVICE
+   headless:
+     postfix: NONE
+     annotations:
+       anotherAnnotationsKey : value
+     publishNotReadyAddresses: true
+   headlessPorts:
+   - name: tcp-MyPort
+     port: 5432
+   - name: http-api
+     port: 8080
+   - name: https-api
+     port: 9443
+
+`headless.annotations`, `headless.postfix` and
+`headless.publishNotReadyAddresses` keys are optional.
+
+If `headless.postfix` is not set, then we'll add `-headless` at the end of the
+service name.
+
+If it set to `NONE`, there will be not postfix.
+
+And if set to something, it will add `-something` at the end of the service
+name.
+
+It would render the following Service Resource (for a component named
+`name-of-my-component`, with version `x.y.z`, helm deployment name
+`my-deployment` and `global.nodePortPrefix` `302`):
+
+.. code-block:: yaml
+
+  apiVersion: v1
+  kind: Service
+  metadata:
+    annotations:
+      anotherAnnotationsKey: value
+    name: NAME-OF-THE-SERVICE
+    labels:
+      app.kubernetes.io/name: name-of-my-component
+      helm.sh/chart: name-of-my-component-x.y.z
+      app.kubernetes.io/instance: my-deployment-name-of-my-component
+      app.kubernetes.io/managed-by: Tiller
+  spec:
+    clusterIP: None
+    ports:
+      - port: 5432
+        targetPort: tcp-MyPort
+        nodePort: 30288
+      - port: 8080
+        targetPort: http-api
+        nodePort: 30289
+      - port: 9443
+        targetPort: https-api
+        nodePort: 30290
+    publishNotReadyAddresses: true
+    selector:
+      app.kubernetes.io/name: name-of-my-component
+      app.kubernetes.io/instance:  my-deployment-name-of-my-component
+    type: ClusterIP
+
+Previous example of StatefulSet would also match (except for the `postfix` part
+obviously).
+
+Creating Deployment or StatefulSet
+----------------------------------
+
+Deployment and StatefulSet should use the `apps/v1` (which has appeared in
+v1.9).
+As seen on the service part, the following parts are mandatory:
+
+.. code-block:: yaml
+
+  apiVersion: apps/v1
+  kind: StatefulSet
+  metadata:
+    name: {{ include "common.fullname" . }}
+    namespace: {{ include "common.namespace" . }}
+    labels: {{- include "common.labels" . | nindent 4 }}
+  spec:
+    selector:
+      matchLabels: {{- include "common.matchLabels" . | nindent 6 }}
+    # serviceName is only needed for StatefulSet
+    # put the postfix part only if you have add a postfix on the service name
+    serviceName: {{ include "common.servicename" . }}-{{ .Values.service.postfix }}
+    <...>
+    template:
+      metadata:
+        labels: {{- include "common.labels" . | nindent 8 }}
+        annotations: {{- include "common.tplValue" (dict "value" .Values.podAnnotations "context" $) | nindent 8 }}
+        name: {{ include "common.name" . }}
+      spec:
+        <...>
+        containers:
+          - name: {{ include "common.name" . }}
 
 ONAP Application Configuration
 ------------------------------
 
 ONAP Application Configuration
 ------------------------------
@@ -422,18 +619,16 @@ SO deployment specification excerpt:
 
 .. code-block:: yaml
 
 
 .. code-block:: yaml
 
-  apiVersion: extensions/v1beta1
+  apiVersion: apps/v1
   kind: Deployment
   metadata:
   kind: Deployment
   metadata:
-    name: {{ include "common.name" . }}
+    name: {{ include "common.fullname" . }}
     namespace: {{ include "common.namespace" . }}
     namespace: {{ include "common.namespace" . }}
-    labels:
-      app: {{ include "common.name" . }}
-      chart: {{ .Chart.Name }}-{{ .Chart.Version | replace "+" "_" }}
-      release: {{ .Release.Name }}
-      heritage: {{ .Release.Service }}
+    labels: {{- include "common.labels" . | nindent 4 }}
   spec:
     replicas: {{ .Values.replicaCount }}
   spec:
     replicas: {{ .Values.replicaCount }}
+    selector:
+      matchLabels: {{- include "common.matchLabels" . | nindent 6 }}
     template:
       metadata:
         labels:
     template:
       metadata:
         labels:
@@ -442,7 +637,7 @@ SO deployment specification excerpt:
       spec:
         initContainers:
         - command:
       spec:
         initContainers:
         - command:
-          - /root/ready.py
+          - /app/ready.py
           args:
           - --container-name
           - so-mariadb
           args:
           - --container-name
           - so-mariadb
@@ -461,7 +656,8 @@ describe the configuration and desired state of the ONAP components.
 
 Name Spaces
 -----------
 
 Name Spaces
 -----------
-Within the namespaces are Kubernetes services that provide external connectivity to pods that host Docker containers.
+Within the namespaces are Kubernetes services that provide external
+connectivity to pods that host Docker containers.
 
 ONAP Components to Kubernetes Object Relationships
 --------------------------------------------------
 
 ONAP Components to Kubernetes Object Relationships
 --------------------------------------------------
@@ -639,7 +835,8 @@ OOM Networking with Kubernetes
 ------------------------------
 
 - DNS
 ------------------------------
 
 - DNS
-- Ports - Flattening the containers also expose port conflicts between the containers which need to be resolved.
+- Ports - Flattening the containers also expose port conflicts between the
+  containers which need to be resolved.
 
 Node Ports
 ~~~~~~~~~~
 
 Node Ports
 ~~~~~~~~~~
@@ -813,7 +1010,7 @@ MSB service discovery. The following is a brief description of how this
 integration will be done:
 
 A registrator to push the service endpoint info to MSB service
 integration will be done:
 
 A registrator to push the service endpoint info to MSB service
-discovery. 
+discovery.
 
 -  The needed service endpoint info is put into the kubernetes yaml file
    as annotation, including service name, Protocol,version, visual
 
 -  The needed service endpoint info is put into the kubernetes yaml file
    as annotation, including service name, Protocol,version, visual
@@ -932,19 +1129,20 @@ access to watch the kubernetes events and get service annotation by
 Kubernetes APIs. The token can be found in the kubectl configuration file
 *~/.kube/config*
 
 Kubernetes APIs. The token can be found in the kubectl configuration file
 *~/.kube/config*
 
-More details can be found here `MSB installation <http://onap.readthedocs.io/en/latest/submodules/msb/apigateway.git/docs/platform/installation.html>`__.
+More details can be found here `MSB installation <https://docs.onap.org/projects/onap-msb-apigateway/en/latest/platform/installation.html>`_.
 
 .. MISC
 .. ====
 .. Note that although OOM uses Kubernetes facilities to minimize the effort
 
 .. MISC
 .. ====
 .. Note that although OOM uses Kubernetes facilities to minimize the effort
-.. required of the ONAP component owners to implement a successful rolling upgrade
-.. strategy there are other considerations that must be taken into consideration.
+.. required of the ONAP component owners to implement a successful rolling
+.. upgrade strategy there are other considerations that must be taken into
+.. consideration.
 .. For example, external APIs - both internal and external to ONAP - should be
 .. For example, external APIs - both internal and external to ONAP - should be
-.. designed to gracefully accept transactions from a peer at a different software
-.. version to avoid deadlock situations. Embedded version codes in messages may
-.. facilitate such capabilities.
+.. designed to gracefully accept transactions from a peer at a different
+.. software version to avoid deadlock situations. Embedded version codes in
+.. messages may facilitate such capabilities.
 ..
 ..
-.. Within each of the projects a new configuration repository contains all of the
-.. project specific configuration artifacts.  As changes are made within the
-.. project, it's the responsibility of the project team to make appropriate
+.. Within each of the projects a new configuration repository contains all of
+.. the project specific configuration artifacts.  As changes are made within
+.. the project, it's the responsibility of the project team to make appropriate
 .. changes to the configuration data.
 .. changes to the configuration data.