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)
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:
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