CPS-320 - Remove Duplicate Application Configuration in OOM

Owned by renu kumari
Last updated: Apr 19, 2021
2 min read

CPS-320: Remove configuration duplication in OOMClosed

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.

  1. configured in the application.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.