spring-cloud-kubernetes: Cannot load multiple mounted configmap with multiple application.yaml
I would like to use multiple mounted config maps and according to the source code KubernetesPropertySource.java, same key application.yaml will be overwritten in the result HashMap which causes that multiple config maps cannot be loaded at the same time and only the last mounted configmap that has the same key can be loaded successfully. Need a help since I am not sure if this is the design or it is a bug. Also I tried consuming configmap from API which works.
Configuration files:
# configmap
apiVersion: v1
kind: ConfigMap
metadata:
name: configmap-spring-1
namespace: {{ .Release.Namespace }}
data:
application.yaml: |-
deployment:
type: cloud
name: beta
# configmap
apiVersion: v1
kind: ConfigMap
metadata:
name: configmap-spring-2
namespace: {{ .Release.Namespace }}
data:
application.yaml: |-
{{ .Files.Get "application.yaml" | indent 4 }}
---
spring.profiles: {{ .Values.springProfile }}
{{ .Files.Get (printf "application-%s.yaml" .Values.springProfile) | indent 4 }}
# values.yaml
springProperties:
spring:
cloud:
kubernetes:
config:
enableApi: false
paths:
- "/home/configmaps"
reload:
enabled: true
About this issue
- Original URL
- State: closed
- Created 6 years ago
- Comments: 20 (13 by maintainers)
Commits related to this issue
- Rationalize ConfigMap usage when paths (mounted files) are involved This is done by removing the file walking and loading logic that existed before and replacing it with an implementation that create... — committed to geoand/spring-cloud-kubernetes by geoand 6 years ago
- Rationalize ConfigMap usage when paths (mounted files) are involved This is done by removing the file walking and loading logic that existed before and replacing it with an implementation that create... — committed to geoand/spring-cloud-kubernetes by geoand 6 years ago
- Rationalize ConfigMap usage when paths (mounted files) are involved This is done by removing the file walking and loading logic that existed before and replacing it with an implementation that create... — committed to geoand/spring-cloud-kubernetes by geoand 6 years ago
- Rationalize ConfigMap usage when paths (mounted files) are involved This is done by removing the file walking and loading logic that existed before and replacing it with an implementation that create... — committed to geoand/spring-cloud-kubernetes by geoand 6 years ago
- Rationalize ConfigMap usage when paths (mounted files) are involved This is done by removing the file walking and loading logic that existed before and replacing it with an implementation that create... — committed to geoand/spring-cloud-kubernetes by geoand 6 years ago
- Rationalize ConfigMap usage when paths (mounted files) are involved This is done by removing the file walking and loading logic that existed before and replacing it with an implementation that create... — committed to spring-cloud/spring-cloud-kubernetes by geoand 6 years ago
If I get one more OK I will start working on this one based on the suggestion by @william-tran
The limitation of using spring boot’s existing spring.config.location behaviour is that you aren’t setting the precedence of those property sources in the same way as other spring-cloud-config implementations which order this with highest precedence.
Rather than merging the values into a single property source, I would expect support for multiple configmaps would allow the user to define precedence in the order of declaration e.g. for file mounted configmaps, the order of entries in
spring.cloud.kubernetes.config.paths. Each entry would result in a PropertySource in the order provided. This way, sc-k8s doesn’t need to deal with any merging of properties.