kustomize: Name in a configMapRef is not updated to include the hash as a suffix (nor a prefix)

What happened?

While upgrading from an older version kustomize I discovered a breaking change in output between v3.9.2 and v3.9.3, where a configMapRef is no longer valid.

~While this behaviour appeared in v3.9.3, it can be reverted by applying the --enable_kyaml=false flag and from looking at the release notes for v3.9.3 I believe the difference is actually due to the switch to the kyaml library.~ (I was wrong about this!)

I think it’s different to other GitHub issues I’ve found (e.g. #1301 or #2609) as I can still replicate this on v5.0.0.

What did you expect to happen?

A hash and suffix to still be included in the configMapRef, i.e. a-example-configmap-6ct58987ht rather than -example-configmap.

Interestingly building a or b independently (or removing either - a or - b from the kustomization.yaml) still gives the expected behaviour. It’s only when there are multiple resources that this unexpected behaviour occurs.

Perhaps I was previously relying on undefined/buggy behaviour?

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

# kustomization.yaml
resources:
- a
- b
# a/kustomization.yaml
resources:
- ../common

namePrefix: a
# b/kustomization.yaml
resources:
- ../common

namePrefix: b
# common/kustomization.yaml
resources:
- service

configMapGenerator:
- name: "-example-configmap"
# common/service/deployment.yaml
kind: Deployment
apiVersion: apps/v1

metadata:
  name: "-"

spec:
  template:
    spec:
      containers:
      - name: app
        envFrom:
        - configMapRef:
            name: "-example-configmap"
# common/service/kustomization.yaml
resources:
- deployment.yaml

nameSuffix: api

I also have a copy of these files here https://github.com/jonathanlking/kustomize-example.

Expected output

apiVersion: v1
kind: ConfigMap
metadata:
  name: a-example-configmap-6ct58987ht
---
apiVersion: v1
kind: ConfigMap
metadata:
  name: b-example-configmap-6ct58987ht
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: a-api
spec:
  template:
    spec:
      containers:
      - envFrom:
        - configMapRef:
            name: a-example-configmap-6ct58987ht
        name: app
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: b-api
spec:
  template:
    spec:
      containers:
      - envFrom:
        - configMapRef:
            name: b-example-configmap-6ct58987ht
        name: app

Actual output

apiVersion: v1
kind: ConfigMap
metadata:
  name: a-example-configmap-6ct58987ht
---
apiVersion: v1
kind: ConfigMap
metadata:
  name: b-example-configmap-6ct58987ht
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: a-api
spec:
  template:
    spec:
      containers:
      - envFrom:
        - configMapRef:
            name: -example-configmap
        name: app
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: b-api
spec:
  template:
    spec:
      containers:
      - envFrom:
        - configMapRef:
            name: -example-configmap
        name: app

Kustomize version

v3.9.3 onwards (including v5.0.0)

Operating system

Linux

About this issue

  • Original URL
  • State: open
  • Created a year ago
  • Comments: 16 (5 by maintainers)

Most upvoted comments

Though this is not yet conclusive, I was able to pinpoint the PR in which the regression was introduced. Pull Request: https://github.com/kubernetes-sigs/kustomize/pull/3529

Gotta ❤️ Git with its bisect command!

I will go through the changes in this PR and try to identify which specific change is causing this behaviour.

@jonathanlking, thanks for the specific versions in the description, this helped a lot!

@Serializator Ah, yes I did misunderstand! 🤦‍♂️

You’re saying that the patch could be replace and instead the deployment could be changed to:

kind: Deployment
apiVersion: apps/v1

metadata:
  name: "-"

spec:
  template:
    spec:
      containers:
      - name: app
        envFrom:
        - configMapRef:
            name: "-example-configmap"

I agree, you’re right, the patch included does not affect the outcome. Apologies for this, I’m not sure how I missed it, I will update the example.

/assign