carvel-dev / kapp

kapp is a simple deployment tool focused on the concept of "Kubernetes application" — a set of resources with the same label
https://carvel.dev/kapp
Apache License 2.0
899 stars 108 forks source link

Detect ConfigMap change from kustomize smartly #81

Open yujunz opened 4 years ago

yujunz commented 4 years ago

Kustomize will generate a ConfigMap suffix automatically, which makes the change like delete and create.

Namespace        Name               Kind        Conds.  Age  Op      Wait to    Rs  Ri
something-test   conf-d-7g4t7m57mg  ConfigMap   -       9m   delete  delete     ok  -
^                conf-d-dc5dg9m84f  ConfigMap   -       -    create  reconcile  -   -

Is it possible to smartly detect it as a resource change to highlight the diff?

cppforlife commented 4 years ago

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")?

yujunz commented 4 years ago

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.

ciis0 commented 2 years ago

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.

rochacon commented 2 years ago

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