Support for diffing kubernetes configmap content

[SrslyJosh]

Right now, dyff treats configmaps like every other resource, which means that if there's a one-line difference in a hundred-line file, dyff will print all 100 lines of both old and new content.

It'd be nice if dyff detected that a resource was a configmap and diffed the content instead of treating values in the configmap as atomic. (I hope that makes sense.)

[HeavyWombat]

I think I know what you mean. Will have a look.

[jvanzyl]

I think what is meant is that the content of the data field is not canonicalized before comparison. In the specific example I have the first ConfigMap has a big embedded string, while the second is inline text:

apiVersion: v1
kind: ConfigMap
metadata:
  name: pinniped-concierge-config
  namespace: pinniped-concierge
  labels:
    app: pinniped-concierge
data:
  pinniped.yaml: "discovery:\n  url: null\napi:\n  servingCertificate:\n    durationSeconds: 2592000\n    renewBeforeSeconds: 2160000\napiGroupSuffix: pinniped.dev\n# aggregatedAPIServerPort may be set here, although other YAML references to the default port (10250) may also need to be updated\n# impersonationProxyServerPort may be set here, although other YAML references to the default port (8444) may also need to be updated\nnames:\n  servingCertificateSecret: pinniped-concierge-api-tls-serving-certificate\n  credentialIssuer: pinniped-concierge-config\n  apiService: pinniped-concierge-api\n  impersonationLoadBalancerService: pinniped-concierge-impersonation-proxy-load-balancer\n  impersonationClusterIPService: pinniped-concierge-impersonation-proxy-cluster-ip\n  impersonationTLSCertificateSecret: pinniped-concierge-impersonation-proxy-tls-serving-certificate\n  impersonationCACertificateSecret: pinniped-concierge-impersonation-proxy-ca-certificate\n  impersonationSignerSecret: pinniped-concierge-impersonation-proxy-signer-ca-certificate\n  agentServiceAccount: pinniped-concierge-kube-cert-agent\nlabels: {\"app\":\"pinniped-concierge\"}\nkubeCertAgent:\n  namePrefix: pinniped-concierge-kube-cert-agent-\n  \n  \n  image: projects.registry.vmware.com/pinniped/pinniped-server:latest\n  \n  \n  \n\n"

Versus

---
# Source: pinniped-concierge/templates/configmap-pinniped-concierge-config.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: pinniped-concierge-config
  namespace: 'pinniped-concierge'
  labels:
    app: pinniped-concierge
data:
  pinniped.yaml: |
    discovery:
      url: null
    api:
      servingCertificate:
        durationSeconds: 2592000
        renewBeforeSeconds: 2160000
    apiGroupSuffix: pinniped.dev
    # aggregatedAPIServerPort may be set here, although other YAML references to the default port (10250) may also need to be updated
    # impersonationProxyServerPort may be set here, although other YAML references to the default port (8444) may also need to be updated
    names:
      servingCertificateSecret: pinniped-concierge-api-tls-serving-certificate
      credentialIssuer: pinniped-concierge-config
      apiService: pinniped-concierge-api
      impersonationLoadBalancerService: pinniped-concierge-impersonation-proxy-load-balancer
      impersonationClusterIPService: pinniped-concierge-impersonation-proxy-cluster-ip
      impersonationTLSCertificateSecret: pinniped-concierge-impersonation-proxy-tls-serving-certificate
      impersonationCACertificateSecret: pinniped-concierge-impersonation-proxy-ca-certificate
      impersonationSignerSecret: pinniped-concierge-impersonation-proxy-signer-ca-certificate
      agentServiceAccount: pinniped-concierge-kube-cert-agent
    labels: {"app": "pinniped-concierge"}
    kubeCertAgent:
      namePrefix: pinniped-concierge-kube-cert-agent-
      image: projects.registry.vmware.com/pinniped/pinniped-server:latest

[HeavyWombat]

This makes perfect sense. Thanks for the example. I tried something like that some time ago to improve the output for multi-line strings. Back then, the context was to get a better output when comparing certificates. I am not a super big fan of my code from back then, but my idea was to simplify and unify what was done and apply it with regards to the context of Kubernetes ConfigMaps.

Originally, dyff was for plain YAMLs and BOSH manifests as well as the occasional Cloud Foundry release manifest. For me, the focus has shifted more towards Kubernetes files so I am more than happy with any feedback and suggestions in that area.

[souleb]

We would like to take advantage of this in Flux where we use dyff to render kubernetes ssa dry-run

fluxcd/flux2#2400