Show diff for actual state vs desired state

[dudicoco]

Hi,
At the moment, if you make any manual changes to resources (not via helm) helm diff will not reflect these changes.
I suggest that the output should reflect the desired vs actual state of the resources, just like running terraform plan.

[databus23]

That would be nice but its not straightforward. The problem is that Kubernetes controllers/operators add a lot of fields when working with the resources. For example the common metadata section alone is modified a lot. Also a lot of fields in the Spec section of almost all resources are filled with default values (e.g. spec.revisionHistoryLimit of Deployments)
So its not easy to create a meaningful diff. You would always see a lot of noise that would hide the actual changes.

[dudicoco]

@databus23 what about using kubectl-diff behind the scenes after rendering the templates?

[databus23]

what about using kubectl-diff behind the scenes after rendering the templates?

Not sure I follow you. What do you mean by that? Against what would you diff the rendered templates? The actual state from the cluster is littered with dozens of default values that are not in the rendered templates. This would in almost all cases create a huge diff that has no meaning.

[dudicoco]

What I mean is that when running helm-diff the following will happen:

1. The package will be rendered.
2. helm diff will run kubectl diff package.yaml

Example of output which includes the diff from the actual state of the clustered:

kubectl diff -f test.yaml
diff -u -N /var/folders/fj/scl5dj6d13b7mb34kxzwwfp80000gn/T/LIVE-912218788/v1.Pod.default.liveness-exec /var/folders/fj/scl5dj6d13b7mb34kxzwwfp80000gn/T/MERGED-153443763/v1.Pod.default.liveness-exec
--- /var/folders/fj/scl5dj6d13b7mb34kxzwwfp80000gn/T/LIVE-912218788/v1.Pod.default.liveness-exec	2020-01-20 16:04:27.000000000 +0200
+++ /var/folders/fj/scl5dj6d13b7mb34kxzwwfp80000gn/T/MERGED-153443763/v1.Pod.default.liveness-exec	2020-01-20 16:04:27.000000000 +0200
@@ -7,7 +7,7 @@
     kubernetes.io/psp: eks.privileged
   creationTimestamp: "2020-01-20T13:42:14Z"
   labels:
-    test: liveness-exec
+    test: liveness
   name: liveness-exec
   namespace: default
   resourceVersion: "34961066"

[corradomatt]

I tested this using kubectl diff and was able to get a simple diff rendering. Here's what I did...

1. Installed 6 helm charts using helmfile.
2. Manually patched the image field on 1 of the deployments of 1 helm chart.
3. Output the manifest templates from our helmfile using helmfile template > test.yaml.
4. Ran kubectl diff -f test.yaml

The results were to show only 2 differences:

1. An increment of the generation field of the deployment.
2. The image field change as expected.

Seems to me that this suggestion could be a viable solution.

(btw - thank you for this package!)

[TJM]

helm/helm-www#521 <-- I filed this in the wrong place, guess you already know about this :)

[TJM]

For what its worth, I tried what @corradomatt mentioned above, but had pages of output, likely due to everything not being in one namespace. Apparently, to do this I would have to separate the comparison by namespace (somehow?).

[corradomatt]

I've been using the following to run diffs now...

# using helmfile
helmfile -e myenv template | kubectl diff -f - | bat -l diff -

# using helm directly
helm template releaseName chart | kubectl diff -f - | bat -l diff -

You could easily apply your namespace flags to these commands and/or supply a selector to helmfile to limit the output. This also uses the bat utility (which is amazing btw).

[sstarcher]

On this note now that helm 3 is doing a 3 way merge could we not look at the code they are using for the merge.

[max-rocket-internet]

I would just like to also mention the importance of having this feature 🙂

Before, with Helm2, showing a diff excluding manual changes in the cluster was fine because Helm2 would also ignore these. But now, with Helm3 and the new 3-way merge, we can't really be sure of what will be applied to the cluster when using this plugin. If the upgrade is going to revert some manual changes then this plugin won't show them.

[sstarcher]

Agreed this is much more important now. It is also needed to help debug why a 3 way merges in helm maybe not acting as we expect.

[TBBle]

To support helm/helm#7649, it'd be handy if the "actual state" diff side in this feature could be one not provided by Helm. Obviously, in such a case, only objects created by the Helm release would be considered, although it might be handy to explicitly flag objects that exist but are missing the appropriate annotations (although they'd show up in the diff anyway).