Page Comparison

...

In any spring application, application properties can be provided in multiple ways, which are mentioned listed below in ascending order of priority.

1. applicationconfigured in thebapplication.yml in the resources folder 
2. configured in the application-<profile>.yml in the resources folder
3. environment variables
4. 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.