diff stringData with data

[yujunz]

Describe the problem/challenge you have

Secrets created with stringData is treated as delete and add.

  0,  0   apiVersion: v1
  1     - data:
  2     -   oidc.config.clientSecret: <-- value not shown (#1)
      1 + data: {}
  4,  2   kind: Secret
  5,  3   metadata:
  ...
 17, 15     uid: 3e4606fc-32d9-11eb-88c8-ac1f6b59972e
 18     - type: Opaque
     16 + stringData:
     17 +   oidc.config.clientSecret: <-- value not shown (#3)

Describe the solution you'd like

Compare the content of data and stringData to show the real difference

Anything else you would like to add:

N/A

[gcheadle-vmware]

Hi @yujunz,

Looking at your diff output I'm not sure exactly what is going on, are you switching from using data to using stringData? Also, which diff strategy are you using?

One option to see the values of your secret in the diff is to use --diff-mask flag set to false

[yujunz]

Yeah, kind of that. The simplest way to reproduce.

➜  kubectl create secret generic sample --from-literal=foo=bar
secret/sample created
➜  kapp deploy --app sample --diff-changes --diff-mask=false -f - <<EOF
apiVersion: v1
kind: Secret
metadata:
  name: sample
stringData:
  foo:bar
EOF
Target cluster 'https://127.0.0.1:55000' (nodes: kind-control-plane)

@@ update secret/sample (v1) namespace: default @@
  0,  0   apiVersion: v1
  1     - data:
  2     -   foo: YmFy
  3,  1   kind: Secret
  4,  2   metadata:
  5,  3     creationTimestamp: "2020-12-20T02:45:08Z"
      4 +   labels:
      5 +     kapp.k14s.io/app: "1608431719079672000"
      6 +     kapp.k14s.io/association: v1.f7d675bc068eea2d1c6c52535cb9e452
  6,  7     name: sample
  7,  8     namespace: default
  ...
 10, 11     uid: 105d4fbc-756f-462a-a6c9-4e133111d585
 11     - type: Opaque
     12 + stringData: foo:bar

It does not actually modify the content of secret except the kapp notations.

[cari-lynn]

Hey @yujunz , thanks for adding the reproduction steps.

Following the steps, creating a secret via kubectl create secret generic sample --from-literal=foo=bar Creates a resource in the cluster that looks like this:

apiVersion: v1
kind: Secret
data:
  foo: YmFy

Updating the secret with the second command attempts to diff the above with a resource that looks like this:

apiVersion: v1
kind: Secret
metadata:
  name: sample
stringData:
  foo: bar

Notably, the key data and stringData are different.

Since kapp's diff compares the input against resources that exist in Kubernetes API, it sees the difference in key name as an update.

What would you like the output of this diff to look like?

Additionally, it is valid to have a secret with both data and stringData. In this case, what would you imagine the diff to look like?

[yujunz]

Since kapp's diff compares the input against resources that exist in Kubernetes API, it sees the difference in key name as an update.

This design makes sense. But normally end user would expect a diff of output instead of input at least on my side.

Applying stringData will also resulted in data in kubernetes resource on my side.

❯ kubectl get secret sample -o yaml
apiVersion: v1
data:
  foo: YmFy
kind: Secret
metadata:
  annotations:
    kapp.k14s.io/identity: v1;default//Secret/sample;v1
    kapp.k14s.io/original: '{"apiVersion":"v1","kind":"Secret","metadata":{"labels":{"kapp.k14s.io/app":"1609915378573538000","kapp.k14s.io/association":"v1.f7d675bc068eea2d1c6c52535cb9e452"},"name":"sample","namespace":"default"},"stringData":{"foo":"bar"}}'
    kapp.k14s.io/original-diff-md5: c30a6989f4160bcc7194737075867fd3
  creationTimestamp: "2021-01-06T06:42:36Z"
  labels:
    kapp.k14s.io/app: "1609915378573538000"
    kapp.k14s.io/association: v1.f7d675bc068eea2d1c6c52535cb9e452
  name: sample
  namespace: default
  resourceVersion: "414664242"
  selfLink: /api/v1/namespaces/default/secrets/sample
  uid: 5ca8e4dc-4fea-11eb-9979-ac1f6b4ea082
type: Opaque

Note stringData in kapp annotation and data in resource yaml. The output is actually not changed at all while the diff preview gives me a wrong message that it will modify something. And if the content did get modified, it will likely get ignored if user assume it is normal.

Anyway, it is literally a case of importing existing secret to kapp. It won't show up when run again. When you say diff compares the input against that exist in Kubernetes API, are you referring to the kapp original annotation?

[danielhelfand]

When you say diff compares the input against that exist in Kubernetes API, are you referring to the kapp original annotation?

In reading @pivotal-dean's original message, I am assuming she was referring to the key as the stringdata, not the kapp annotation.

But after reading over everything in the issue, we think it makes sense that it is a bit confusing to include the input data in the diff as you were saying. We'll try to introduce this into our backlog to see what the right approach to this would be.

Thanks again for bring this to our attention.

//cc @DennisDenuto