X-Git-Url: https://gerrit.onap.org/r/gitweb?a=blobdiff_plain;f=docs%2Fsections%2Fguides%2Fdevelopment_guides%2Foom_dev_helm_chart_info.rst;fp=docs%2Fsections%2Fguides%2Fdevelopment_guides%2Foom_dev_helm_chart_info.rst;h=533f60e29b09a7bc18fb340a7566ec80aca1591a;hb=0fb3b8f4d48a066259b8a9ea2a18d68d7644f8e5;hp=0000000000000000000000000000000000000000;hpb=66789f218b8464f28a08572ef0c30dbfe40b13c5;p=oom.git

diff --git a/docs/sections/guides/development_guides/oom_dev_helm_chart_info.rst b/docs/sections/guides/development_guides/oom_dev_helm_chart_info.rst
new file mode 100644
index 0000000000..533f60e29b
--- /dev/null
+++ b/docs/sections/guides/development_guides/oom_dev_helm_chart_info.rst
@@ -0,0 +1,172 @@
+.. This work is licensed under a Creative Commons Attribution 4.0
+.. International License.
+.. http://creativecommons.org/licenses/by/4.0
+.. Copyright 2018-2020 Amdocs, Bell Canada, Orange, Samsung
+.. Modification copyright (C) 2022 Nordix Foundation
+
+.. Links
+.. _Helm Charts: https://artifacthub.io/packages/search
+.. _aai: https://github.com/onap/oom/tree/master/kubernetes/aai
+.. _name.tpl: https://github.com/onap/oom/blob/master/kubernetes/common/common/templates/_name.tpl
+.. _namespace.tpl: https://github.com/onap/oom/blob/master/kubernetes/common/common/templates/_namespace.tpl
+
+.. _oom_helm_chart_info:
+
+Helm Charts
+###########
+
+A Helm chart is a collection of files that describe a related set of Kubernetes
+resources. A simple chart might be used to deploy something simple, like a
+memcached pod, while a complex chart might contain many micro-service arranged
+in a hierarchy as found in the `aai`_ ONAP component.
+
+Charts are created as files laid out in a particular directory tree, then they
+can be packaged into versioned archives to be deployed. There is a public
+archive of `Helm Charts`_ on ArtifactHUB that includes many technologies applicable
+to ONAP. Some of these charts have been used in ONAP and all of the ONAP charts
+have been created following the guidelines provided.
+
+An example structure of the OOM common helm charts is shown below:
+
+.. 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
+
+The common section of charts consists of a set of templates that assist with
+parameter substitution (`name.tpl`_, `namespace.tpl`_, etc) 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.
+
+All of the ONAP components have charts that follow the pattern 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 /components sub dir 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
+
+  ---
+  global:
+    key: value
+
+  component1:
+    enabled: true
+  component2:
+    enabled: true
+
+Then in `Chart.yaml` dependencies section, you'll use these values:
+
+.. code-block:: yaml
+
+  ---
+  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
+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.
+
+
+.. 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.
+.. 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.
+..
+.. 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.