Suffix not added to ConfigMap name

[tcurdt]

What happened?

I am trying to use kustomize to rewrite ConfiMap names to include a hash suffix.
Ideally the suffix is based on the content of the ConfigMap.

What did you expect to happen?

Since I am merging an existing ConfigMap with an empty one from the generator, I would have expected for the content hash of the final content to be added as a suffix.

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

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

resources:
- caddy.yaml

generatorOptions:
  disableNameSuffixHash: false

configMapGenerator:
  - name: caddy
    namespace: infra
    behavior: merge

# caddy.yaml
---
apiVersion: v1
kind: ConfigMap
metadata:
  namespace: infra
  name: caddy
  labels:
    app: caddy
data:
  Caddyfile: |
    {
    }

---
apiVersion: apps/v1
kind: Deployment
metadata:
  namespace: infra
  name: caddy
  labels:
    app: caddy
spec:
  replicas: 1
  selector:
    matchLabels:
      app: caddy
  template:
    metadata:
      labels:
        app: caddy
    spec:
      containers:
        - name: caddy
          image: caddy:2.7.6-alpine
      volumes:
        - name: caddy-config
          configMap:
            name: caddy

Expected output

apiVersion: v1
data:
  caddy-configmap.yaml: |
    apiVersion: v1
    kind: ConfigMap
    metadata:
      namespace: infra
      name: caddy
      labels:
        app: caddy
    data:
      Caddyfile: |
        {
        }
kind: ConfigMap
metadata:
  labels:
    app: caddy
  name: caddy-AB1234
  namespace: infra
---
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: caddy
  name: caddy
  namespace: infra
spec:
  replicas: 1
  selector:
    matchLabels:
      app: caddy
  template:
    metadata:
      labels:
        app: caddy
    spec:
      containers:
      - image: caddy:2.7.6-alpine
        name: caddy
      volumes:
      - configMap:
          name: caddy-AB1234
        name: caddy-config

Actual output

apiVersion: v1
data:
  Caddyfile: |
    {
    }
kind: ConfigMap
metadata:
  labels:
    app: caddy
  name: caddy
  namespace: infra
---
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: caddy
  name: caddy
  namespace: infra
spec:
  replicas: 1
  selector:
    matchLabels:
      app: caddy
  template:
    metadata:
      labels:
        app: caddy
    spec:
      containers:
      - image: caddy:2.7.6-alpine
        name: caddy
      volumes:
      - configMap:
          name: caddy
        name: caddy-config

Kustomize version

v5.4.2

Operating system

MacOS

[tcurdt]

This seems like a similar problem as described here #5223

[tcurdt]

Some more testing. No matter what strategy is used (merge or even replace), when there is a previous ConfigMap exists, the suffix appending does not work.

[tcurdt]

Seems what I want is a HashTransformer, the question is what defines NeedHashSuffix.

Based on BuildAnnotationsGenAddHashSuffix = konfig.ConfigAnnoDomain + "/needsHashSuffix" I tried to just add an annotation of

  annotations:
    internal.config.kubernetes.io/needsHashSuffix: true

but I don't see how to add the HashTransformer yet.

[tcurdt]

This seems to be more than related #4833

[tcurdt]

I can confirm that the following annotation

internal.config.kubernetes.io/needsHashSuffix: enabled

makes it work with

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

resources:
- caddy.yaml

generatorOptions:
  disableNameSuffixHash: false

[stormqueen1990]

Hi there, @tcurdt! Thanks for reporting this issue!

I am a little confused with your expected output. Did you expect the existing ConfigMap to be embedded on a new ConfigMap generated by Kustomize?

/triage needs-information

[tcurdt]

I am a little confused with your expected output. Did you expect the existing ConfigMap to be embedded on a new ConfigMap generated by Kustomize?

Hey there, @stormqueen1990, when it says behavior: merge I would have thought it would merge the existing and the generated ConfigMap. In the initial example it would be merging the existing ConfigMap with an empty ConfigMap from the MapGenerator (since no new values are provided).
Since the hashing is enabled I would have thought this also add a hash suffix to the new ConfigMap.

Does that make things clearer?

I still think that's something to fix.

But conceptually, using a transformer with an annotation seems like the cleaner way for my use case.
That said: internal.config.kubernetes.io/needsHashSuffix: enabled really is not a great annotation to rely on. (given the internal and the true vs enabled problem).

But it would be great to officially support such an annotation.

[ephesused]

A quick note that the documentation states:

Name suffixing with overlay configMapGenerator
When using configMapGenerator to override values of an existing ConfigMap, the overlay configMapGenerator does not cause suffixing of the existing ConfigMap’s name to occur. To take advantage of name suffixing, use configMapGenerator in the base, and the overlay generator will correctly update the suffix based on the new content.

[stormqueen1990]

Hey there, @stormqueen1990, when it says behavior: merge I would have thought it would merge the existing and the generated ConfigMap. In the initial example it would be merging the existing ConfigMap with an empty ConfigMap from the MapGenerator (since no new values are provided). Since the hashing is enabled I would have thought this also add a hash suffix to the new ConfigMap.

Does that make things clearer?

Hi @tcurdt, sorry for the delay in getting back to this. I still don't follow why your expected output lists an embedded ConfigMap in a ConfigMap:

apiVersion: v1
data:
  caddy-configmap.yaml: |
    apiVersion: v1
    kind: ConfigMap
    metadata:
      namespace: infra
      name: caddy
      labels:
        app: caddy
    data:
      Caddyfile: |
        {
        }
kind: ConfigMap
metadata:
  labels:
    app: caddy
  name: caddy-AB1234
  namespace: infra

since I don't think that's the goal of behavior: merge. You can, however, achieve this behaviour with Kustomize by creating a ConfigMap with the --from-file option.

I still think that's something to fix.

But conceptually, using a transformer with an annotation seems like the cleaner way for my use case. That said: internal.config.kubernetes.io/needsHashSuffix: enabled really is not a great annotation to rely on. (given the internal and the true vs enabled problem).

But it would be great to officially support such an annotation.

This part is what @ephesused mentioned in the comment prior to this one. Could you give that a try and let me know if it addresses your use case?