Kustomize - Merge multiple configMapGenerators

Question

So I'm dealing with a structure like this:

.
├── 1
│   ├── env-vars
│   └── kustomization.yaml
├── 2
│   ├── env-vars
│   └── kustomization.yaml
├── env-vars
├── kustomization.yaml
└── shared
    ├── env-vars
    └── kustomization.yaml

while env-vars within each level has some env vars and

$cat kustomization.yaml
bases:
- 1/
- 2/

namePrefix: toplevel-

configMapGenerator:
  - name: env-cm
    behavior: merge
    envs:
    - env-vars

$cat 1/kustomization.yaml
bases:
- ./../shared

namePrefix: first-

configMapGenerator:
  - name: env-cm
    behavior: merge
    envs:
    - env-vars

$cat 2/kustomization.yaml
bases:
- ./../shared

namePrefix: second-

configMapGenerator:
  - name: env-cm
    behavior: merge
    envs:
    - env-vars

$cat shared/kustomization.yaml
configMapGenerator:
  - name: env-cm
    behavior: create
    envs:
    - env-vars

I'm essentially trying to create 2 configmaps with some shared values (which are injected from different resources: from shared directory and the top-level directory)

---

kustomize build . fails with some conflict errors for finding multiple objects:

Error: merging from generator <blah>: found multiple objects <blah> that could accept merge of ~G_v1_ConfigMap|~X|env-cm

Unfortunately I need to use merge on the top-level configMapGenerator, since there are some labels injected to 1 and 2 configmaps (so createing a top-level configmap altho addresses the env-vars, but excludes the labels)

Any suggestion on how to address this issue is appreciated

Answer 1

I believe this should solve your issue.

kustomization.yaml which is located in base or /:

$ cat kustomization.yaml 
resources:
- ./1
- ./2

namePrefix: toplevel-

configMapGenerator:
  - name: first-env-cm
    behavior: merge
    envs:
    - env-vars
  - name: second-env-cm
    behavior: merge
    envs:
    - env-vars

With help of search I found this github issue which is I'd say the same issue. And then a pull-request with changes in code. We can see that during kustomize render merge behaviour was changed to look for currentId instead of originalId. Knowing that we can address to exact "pre-rendered" configmaps separately.