Eschewed features
What would you like to have added?
A feature that would allow users to specify a strategy to merge the contents of the file alongside/instead of behavior: merge . Most users need this for configmap merges and properties (k-v) + yaml files. This would allow users to merge all files with identical names into a single file, resolved according to kustomize's overlay rules.
For yaml files it could allow the same behaviour as the actual resource being merged (with schema, named lists support etc). For KV is is a simple merge of a map.
All other files would continue to be merged via the current approach, or possibly through an error if attempted to be merged in the same way.
Option 1
Introduce a new generator option:
generatorOptions:
fileMerge:
mode: content
Concerns
-
Secrets handling
While it makes sense to me that this behaviour should also work for Secrets, due to secret file content encoding we have to decode before merging, and recode again. Even though I tried to implement it in the most careful way possible it still feels off to do that.
-
generatorOptions are global
This is a major issue because lets say I have a file which is a .json config. Since we assume that any non .yaml is a KV config file - we completely corrupt it.
Option 2
Add a field next to behavior for file merge mode with options like content
Or similarly add a new behavior like deep merge or similar
Option 3
Add another source to KvPairSources next to files like file-content or something similar.
Last to options address the concerns of option 1, as they can be configured per configmap. Would love to hear your thoughts on which you concider the best. Of course, the default behaviour will remain the same as now.
Why is this needed?
When using behavior: merge with ConfigMap/Secret generators, files with the same key are completely overridden rather than merged. The behavior: merge only works at the resource level (merging keys), not at the file content level.
For complex configs having them as env vars becomes very cumbersome.
Yaml is a popular configuration format and is very k8s native. Kustomize already has all the necessary logic to merge yaml files, and merging configmap content seems to fit perfectly into the concept of bases and overlays.
This feature was actually showcased in the presentation by Jeff Regan here.
Can you accomplish the motivating task without this feature, and if so, how?
Since the ultimate task is to combine configs inside a file, all those configs would have to be moved up into env variables. Alternatively, we would have to rename the files in the overlays and delegate the configuration merging/overriding logic to the underlying "target" of that config, which defeats the purpose of having the configuration merged via kustomize.
What other solutions have you considered?
For now there doesn't seem to be a straightforward solution that would fit our needs, as we don't have a single technology stack that we could just write a library for.
We have considered helm templating, but that quickly became cumbersome for the hundreds of end users.
Additionally we have considered a Spring Cloud Config service + profiles, but that requires maintaining a whole service + integrating various different stacks to work with it, which is not feasible.
Anything else we should know?
We have already tested this approach in #6050 which is where we have discovered the concerns mentioned for that approach.
We would love to have a discussion regarding this, and will implement it whichever way you seem fit. We are open to any form of communication and would love to get this done as soon as possible.
Please let us know your thoughts, thanks!
Feature ownership
Eschewed features
What would you like to have added?
A feature that would allow users to specify a strategy to merge the contents of the file alongside/instead of
behavior: merge. Most users need this for configmap merges and properties (k-v) + yaml files. This would allow users to merge all files with identical names into a single file, resolved according to kustomize's overlay rules.For yaml files it could allow the same behaviour as the actual resource being merged (with schema, named lists support etc). For KV is is a simple merge of a map.
All other files would continue to be merged via the current approach, or possibly through an error if attempted to be merged in the same way.
Option 1
Introduce a new generator option:
Concerns
Secrets handling
While it makes sense to me that this behaviour should also work for Secrets, due to secret file content encoding we have to decode before merging, and recode again. Even though I tried to implement it in the most careful way possible it still feels off to do that.
generatorOptions are global
This is a major issue because lets say I have a file which is a
.jsonconfig. Since we assume that any non.yamlis a KV config file - we completely corrupt it.Option 2
Add a field next to
behaviorfor file merge mode with options likecontentOr similarly add a new
behaviorlikedeep mergeor similarOption 3
Add another source to
KvPairSourcesnext to files like file-content or something similar.Last to options address the concerns of option 1, as they can be configured per configmap. Would love to hear your thoughts on which you concider the best. Of course, the default behaviour will remain the same as now.
Why is this needed?
When using behavior: merge with ConfigMap/Secret generators, files with the same key are completely overridden rather than merged. The
behavior: mergeonly works at the resource level (merging keys), not at the file content level.For complex configs having them as env vars becomes very cumbersome.
Yaml is a popular configuration format and is very k8s native. Kustomize already has all the necessary logic to merge yaml files, and merging configmap content seems to fit perfectly into the concept of bases and overlays.
This feature was actually showcased in the presentation by Jeff Regan here.
Can you accomplish the motivating task without this feature, and if so, how?
Since the ultimate task is to combine configs inside a file, all those configs would have to be moved up into env variables. Alternatively, we would have to rename the files in the overlays and delegate the configuration merging/overriding logic to the underlying "target" of that config, which defeats the purpose of having the configuration merged via kustomize.
What other solutions have you considered?
For now there doesn't seem to be a straightforward solution that would fit our needs, as we don't have a single technology stack that we could just write a library for.
We have considered helm templating, but that quickly became cumbersome for the hundreds of end users.
Additionally we have considered a Spring Cloud Config service + profiles, but that requires maintaining a whole service + integrating various different stacks to work with it, which is not feasible.
Anything else we should know?
We have already tested this approach in #6050 which is where we have discovered the concerns mentioned for that approach.
We would love to have a discussion regarding this, and will implement it whichever way you seem fit. We are open to any form of communication and would love to get this done as soon as possible.
Please let us know your thoughts, thanks!
Feature ownership