that's an interesting idea. we do something similar for kapp's versioned resources in terms of diff presentation. let me think a bit more about how does one best detect/indicate this relationship.

do you think it would be reasonable to require an annotation on a configmap for this behaviour (and to better detect which resources are "related")?

I was expecting similar behavior to git which is content based, no need for extra annotation. But that might be hard to implement as we don't have an underlying content based storage.

So yes, implement it with annotations sounds good to me, although I don't have any idea about how to do it yet.

Hi,

kustomize by default applies a "name suffix hash" to all ConfigMaps and Secrets it generates via configMapGenerator/secretGenerator, so maybe a "use at your own risk"-flag like diffStripKustomizeNameSuffixHash: yes, simply stripping the -suffix from all CMs and Secrets, might already be quite useful?

Unfortunately custom-written-YAML CMs/Secrets will not get a name-suffix-hash (and i found no way to add it), but that should be a very edge-y use-case.

I stumbled upon this recently and the way I "fixed" it was by delegating the ConfigMap/Secret versioning to kapp instead of kustomize, like this:

# kustomization.yaml

secretGenerator:
- name: a-secret
  options:
    annotations:
      kapp.k14s.io/num-versions: "3"
      kapp.k14s.io/versioned: ""
    disableNameSuffixHash: true
  literals:
  - dont=tell-anyone

Example output:

% kustomize build | kapp deploy --app rochacon-test -n rochacon -f-
Target cluster 'https://...' (nodes: ...)

Changes

Namespace  Name            Kind    Conds.  Age  Op      Op st.  Wait to    Rs  Ri
rochacon   a-secret-ver-1  Secret  -       -    create  -       reconcile  -   -

Op:      1 create, 0 delete, 0 update, 0 noop, 0 exists
Wait to: 1 reconcile, 0 delete, 0 noop

Continue? [yN]: