CPS-320 - Getting issue details... STATUS
Introduction
Currently, the default application configuration is present inside the docker images and it gets overridden when it is deployed using the helm. The issue with this approach is
- maintaining same values at two places
- the possibility of missing a few configurations in the OOM
- having obsolete values in OOM
To avoid it, we can keep only those properties in the OOM which needs to be changed based on deployment and provide an ability for overriding any property if required.
Possible Solutions
Final Approach: Approach 2 - Spring Profile
In any spring application, application properties can be provided in multiple ways, listed below in ascending order of priority.
- configured in thebapplication.yml in the resources folder
- configured in the application-<profile>.yml in the resources folder
- environment variables
- system property to JVM using -Dkey=value
For Example, if property spring.config.max-size = 1000 is defined in application.yml and a new value is set for the same property by the environment variable ( spring.config.max-size = 5000 ), then application will run with value as 5000.
Approach 1 - Using Environment variables
Implementation: https://gerrit.onap.org/r/c/oom/+/120431/1
In this approach, everything will be added in the environment variables which will make it difficult to identify in a running container which spring properties are overridden or added for application. We have to rely on configmap for a large set of environment variables which can make debugging inconvenient.
Approach 2 - Spring Profiles
Implementation: https://gerrit.onap.org/r/c/oom/+/120431/6
In this approach, all new or overridden spring properties will be defined for the profile "helm" in the application-helm.yml file. As all the spring application properties are defined in a file, it makes it simple to find the configuration in a running container without referring to a configmap. It makes debugging simpler than using environment variables. And, the file also has a single responsibility which makes this approach better than Approach 1.
Approach 3 - Keeping application.yml next to spring jar
Implementation: Can't be implemented
Spring boot provides a feature to merge the application.yml, provided next to the spring-boot jar, with the default properties. However, it can not be implemented because jib adds directories instead of a spring-boot app jar in an image.