segregation of configuration for mso component.

We find two approaches to segregate configuration of  

Approach1: Using ConfigMaps of Kubernetes:

• Creation of ConfigMap yaml for individual components (and subcomponents/applications) using the configurations files provided in the src.
  • Once we have the ConfigMaps yaml’s then no real configuration files would be present in the source code, any changes in the configurations should be done by changing the ConfigMaps yaml files.
  • Alternatively, we can have the each components’ configuration files  in config directory parallel to Chart.yaml and templates, ConfigMaps will refer to these physical files. This option will allow future changes in the configurations easy as they would be done in actual config files.
• Change the yaml files for pods to use these ConfigMaps instead of /dockerdata-nfs.
• Replace the onap parameters (or any other parameters) in the ConfigMap yaml files if needed at the time of helm install.
• All the config/src  would be deleted.
• The persistent data portion of any component will continue to be created and used on /dockerdata-nfs itself(will be created using the init containers for respective applications/components).
• sh shall of course be removed.
• Config init container will be removed altogether and will not be used.

Approach2: Modifications in the config-init

• Change the config-init.sh to work for individual applications as provided in the createAll.sh.
  • Script should be made generic to avoid duplication of code.
  • This changed script can be embedded in the image itself or can be mounted from host FS to container at runtime.
• Move the configurations to the components for respective applications parallel to the templates.
• sh shall be removed and helm install for config-init will be called from createAll.sh itself.
• Creation of tar (to be placed on image) will be changed so that it can take the configs from respective component dir for creation of image.

 As we see, ConfigMaps approach is better and cleaner way which uses the K8S’s features to supply the configurations to pods and we find it feasible to implement for MSO.