-
Notifications
You must be signed in to change notification settings - Fork 2.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
kustomize complains that "behavior must be merge or replace" despite dynamic name produced by configMapGenerator #4829
Comments
I realize need to provide more information to explain better. First of all, one may wonder why the However, the same error arises even if the configmap in base is defined with a configMapGenerator rather than being defined as a plain manifest. Here are the files that can be used to observe this:
(this works as expected, not issue or suprise at this point) However, the overlay fails (using the same
|
Thanks for the detailed explanation @tmmorin. I understand the confusions. I think this is actually the nice How kustomize understand the caseKustomize refers its ConfigMap by Why failtwo ConfigMap have the same Two examplesExample 1
In base/manifest.yaml
output
Example 2 In overlay/kustomization.yaml
In base/manifest.yaml
output
|
/triage accepted |
@tmmorin I'll leave this issue open, let me know if you have any questions. |
This issue has not been updated in over 1 year, and should be re-triaged. You can:
For more details on the triage process, see https://www.kubernetes.dev/docs/guide/issue-triage/ /remove-triage accepted |
The Kubernetes project currently lacks enough contributors to adequately respond to all issues. This bot triages un-triaged issues according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale |
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues. This bot triages un-triaged issues according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle rotten |
When using
configMapGenerator
in an overlay, withbehavior: create
, I run into the following error, although the name of the generated configMap once appended with the "-abcde12345" suffix would not result in a collision:This seems to happen because the configMap base name collides with a resource existing in the base kustomization, which seems unexpected because the configmap defined in my overlay has a dynamic name (does not use
options.disableNameSuffixHash: true
).It seems to me that, perhaps, "behavior must be merge or replace" should only be enforced when
disableNameSuffixHash: true
is used.Files that can reproduce the issue
Base:
Overlay definition not behaving as hoped:
An overlay that does nearly the same thing and that is working:
Expected output
I would expect
kustomize build overlay-attempt
to succeed and give the following:Note that
kustomize build overlay-working
works as expected:See below, this approach (use "cm-X" instead of "cm" in the overlay) does not work well for me in my actual use case where I would need to avoid to use a different configmap base name in the overlay.
Actual output
Given that "cm" is the base name of my generated configmap, and not its final name, it seems to me that it is a bug to have this error message.
Kustomize version
Platform
Linux amd64
Additional context
This example reflects what I need to do, except that my actual use case is not with multiple volumes inside a Pod definition. I picked this illustration to make a simplest as possible example.
I can somehow live with the workaround used in "overlay-working" where we make sure that the configmap base name defined in the overlay is different than the one used in the base.
However I would like to have multiple levels of inheritance :
... and I would like to generate overlay2 and overlay3 in a context where I don't want to have to pick a different name at each layer.
Note that "behavior: merge" would also not work in my actual use case, where I need distinct configmap at each layer (a common configmap with distinct keys under "data" does not work for me).
The text was updated successfully, but these errors were encountered: