1st_values.yaml
runtimeProperties:|
druid.broker.http.numConnections=300
druid.server.http.numThreads=180
2nd_values.yaml
runtimePropertiesExtra:|
druid.broker.http.numConnections=500
druid.sql.enable=true
So if I use the command helm template -f 1st_values.yaml -f 2nd_values.yaml .
I'm getting the output like this
runtimeProperties:|
druid.broker.http.numConnections=300
druid.server.http.numThreads=180
druid.broker.http.numConnections=500
druid.sql.enable=true
But ideally it should be like this
druid.server.http.numThreads=180
druid.broker.http.numConnections=500
druid.sql.enable=true
This is my template I'm using, This sucessfully appends the value
runtime.properties: |
{{- with .Values.broker.runtimeProperties -}}
{{ . | nindent 8 }}
{{- end }}
{{- with .Values.broker.runtimePropertiesExtra -}}
{{ . | indent 8 | trim }}
{{- end }}
As far as Helm is concerned, you've given it two values
runtimePropertiesandruntimePropertiesExtrathat both have string values. Helm has no notion of "properties file" as a type, and there are no Helm extension functions that could readily parse or merge these strings.One possibility is to express the settings as YAML structure in the Helm values, and then convert it to a properties file in template code. For example, if the values say
Then you can write a helper function to convert this to properties syntax
Then when you create the ConfigMap, you can use the
mergefunction to combine the two maps:On the off chance that these properties are being used in a Spring Boot application, that framework can directly read YAML files as input, and you can use the Helm
toYamlfunction instead of thedict-to-propertieshelper shown here.merge(Overwrite) does a deep merge, and so you could use a fully-structured YAML block rather than writing out dot-syntax properties.