configMapGenerator unable to replace/merger ConfigMap from a Helm chart

[velp]

What happened?

Kustomize is unable to replace/merge the contents of a ConfigMap if the ConfigMap comes from the Helm generator.

What did you expect to happen?

Kustomize should be able to replace/merge the content of any ConfigMaps regardless if they are local or from the chart.

How can we reproduce it (as minimally and precisely as possible)?

Both options bellow reproducing the problem. Tested behavior:replace, merge.

Option 1:
File kustomization.yaml

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

helmCharts:
- name: vault
  namespace: vault
  releaseName: vault
  repo: https://helm.releases.hashicorp.com
  version: 0.22.0

configMapGenerator:
- behavior: replace
  literals:
  - thing=stuff
  name: vault-config
  namespace: vault
  options:
    disableNameSuffixHash: true

Option 2:
This option was described here: #4799 (comment) but it's not working.

File kustomization.yaml:

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

helmCharts:
- name: vault
  namespace: vault
  releaseName: vault
  repo: https://helm.releases.hashicorp.com
  version: 0.22.0

generators:
- configmap-generator.yaml

File configmap-generator.yaml:

apiVersion: builtin
kind: ConfigMapGenerator
behavior: replace
metadata:
  name: vault-config
  namespace: vault
literals:
  - thing=stuff
options:
  disableNameSuffixHash: true

Of course, this manifest exists in Helm Chart:

$ helm template vault hashicorp/vault -n test --version=0.22.0 | grep "vault-config" -m1 -B3
apiVersion: v1
kind: ConfigMap
metadata:
  name: vault-config

Expected output

It should generate manifests

Actual output

Error: merging from generator &{0xc000297520 <nil>}: id resid.ResId{Gvk:resid.Gvk{Group:"", Version:"v1", Kind:"ConfigMap", isClusterScoped:false}, Name:"vault-config", Namespace:"vault"} does not exist; cannot merge or replace

Kustomize version

v5.5.0

Operating system

MacOS

[k8s-ci-robot]

This issue is currently awaiting triage.

SIG CLI takes a lead on issue triage for this repo, but any Kubernetes member can accept issues by applying the triage/accepted label.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[dosmanak]

I suggest to define helmChart using generator due the issue 4593.
I've been using confiMapGenerator (replace behavior) on top of base with helmChart inflator and it works using
$ kubectl version
Client Version: v1.32.1
Kustomize Version: v5.5.0
Server Version: v1.31.2

---
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

resources:
  - git@git.company.tld:k8s/common/grafana.git?ref=work_in_progress

configMapGenerator:
  - name: mimir-distributed-runtime
    behavior: replace
    namespace: mimir
    files:
      - runtime.yaml=config-mimir-distributed-runtime.yaml

where the base includes another resource with mimir that looks like

---
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

namespace: grafana

generators:
  - helmchart.yaml

---
apiVersion: builtin
kind: HelmChartInflationGenerator
metadata:
  name: grafana-mimir

name: mimir-distributed
repo: https://grafana.github.io/helm-charts
version: 5.4.0
namespace: grafana
valuesFile: helmvalues_mimir.yaml
releaseName: mimir-distributed

[velp]

@dosmanak I've tried your solution but without external repository (because I cannot use one, in my case everything should be in one local directory) and in the first attempt I got the same error:

➜  /tmp cat ./test-pr/kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

generators:
  - helmchart-generator.yaml

configMapGenerator:
- behavior: replace
  literals:
  - thing=stuff
  name: vault-config
  namespace: vault
  options:
    disableNameSuffixHash: true

➜  /tmp cat ./test-pr/helmchart-generator.yaml
apiVersion: builtin
kind: HelmChartInflationGenerator
metadata:
  name: vault

name: vault
repo: https://helm.releases.hashicorp.com
version: 0.22.0
namespace: vault
releaseName: vault

➜  /tmp kustomize build --enable-helm /tmp/test-pr
Error: merging from generator &{0xc000287c70 <nil>}: id resid.ResId{Gvk:resid.Gvk{Group:"", Version:"v1", Kind:"ConfigMap", isClusterScoped:false}, Name:"vault-config", Namespace:"vault"} does not exist; cannot merge or replace

But then I tried both generator in separate files:

➜  /tmp cat ./test-pr/kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

generators:
  - helmchart-generator.yaml
  - configmap-generator.yaml
 
➜  /tmp cat ./test-pr/helmchart-generator.yaml
---
apiVersion: builtin
kind: HelmChartInflationGenerator
metadata:
  name: vault
name: vault
repo: https://helm.releases.hashicorp.com
version: 0.22.0
namespace: vault
releaseName: vault

➜  /tmp cat ./test-pr/configmap-generator.yaml
apiVersion: builtin
kind: ConfigMapGenerator
behavior: replace
metadata:
  name: vault-config
  namespace: vault
literals:
  - thing=stuff
options:
  disableNameSuffixHash: true

and surprisingly but it worked:

➜  /tmp kustomize build --enable-helm /tmp/test-pr | grep "thing" -a5
  name: vault
  namespace: vault
---
apiVersion: v1
data:
  thing: stuff
kind: ConfigMap
metadata:
  labels:
    app.kubernetes.io/instance: vault
    app.kubernetes.io/managed-by: Helm

if anyone is looking for a solution to the same problem, here is a workaround👆🏻. I still think that it shouldn't work like this and generators should have some kind of built-in "priority" that would control that the Helm generator starts before all the others, but this solution also allows you to do it.

[Mlundm]

An alternative workaround to @velp workaround would be to use Components.

Since components are evaluated after resources/generators, they can similarly be used to control the order of execution.

# base/kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

helmCharts:
- name: vault
  namespace: vault
  releaseName: vault
  repo: https://helm.releases.hashicorp.com
  version: 0.22.0

components:
  - config-replace

# base/config-replace/kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1alpha1
kind: Component

configMapGenerator:
- behavior: replace
  literals:
  - thing=stuff
  name: vault-config
  namespace: vault
  options:
    disableNameSuffixHash: true
``

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

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:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle rotten
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

[k8s-ci-robot]

@k8s-triage-robot: Closing this issue, marking it as "Not Planned".

In response to this:

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.