Custom rules for filtering before diff "actual state vs desired state"

[R-omk]

In continuation of #349, #326, #176

I believe that it is necessary to consider some kind of general solution to such issues.

The k8s core itself can change manifests during apply process, but there are many admission webhooks that also can change manifests.

You might consider applying pre-filtering before comparing manifests. For example, it can be used expressions executable with jq or yq.

In addition, a three-way merge does not always produce the desired result. Most often, you need to see the full difference, including those sections that three-way merge would miss.

[R-omk]

In addition, a three-way merge does not always produce the desired result. Most often, you need to see the full difference, including those sections that three-way merge would miss.

Please note that an analogue of this behavior is already present in the helm.

 --force       force resource updates through a replacement strategy

But helm-diff upgrade does not support this option, which means that the actual update of the manifests will not be the same as if we looked at the difference when using --three-way-merge option.

I guess is possible to divide what I described into two different issues.

[R-omk]

I would also like to clarify the terminology regarding the main topic of that ticket #176

What is the "actual state" - these are the manifests that we would receive by executing kubectl get * command. Such objects have already gone through all admission webhooks mutator chains and there is no easy way to see their original representation.

What is the "desired state" - these are the manifests that are obtained after applying mutator chains of admission webhooks to them. Such manifests we would receive by executing kubectl apply --server-side --dry-run=server command (Under the hood, something like this happens when executing a native kubectl diff --server-side=true command). But currently this plugin uses raw manifests instead of final ones for comparison.

Since the helm does not store a "actual/desired/real state" in the release data, I suggest calculating it at the moment before the comparison.
Perhaps for such a comparison, it need to add an option something like --server-side. Thus, I propose to divide manifests into two types: source (which can be formed on the client) and final (which can only be obtained by interacting with a real server), and most importantly - do not try to compare two incompatible types with each other.

My opinion at the moment is that the added --three-way-merge option doesn't really solve that issue.

[mumoshu]

@R-omk Thank you so much for your detailed feedback!
Almost certainly you know about this topic more than I do :)

What would be the next action we can take?
Perhaps add an internal filter to helm-diff that works like kubectl apply --servide-side --dry-run=server, so that we can apply all the mutations to both the current manifests(which helm-diff obtains by running helm release get) and the desired manifests(which helm-diff obtains by either helm template or helm upgrade --dry-run)?

That way both inputs to the diff algorithm become "final" and can be safely compared, right?

[R-omk]

I believe that we should not rush to conclusions, I just showed that everything is even more complicated than it might have seemed before.

First, we need to decide what functionality we actually need and whether it is possible.
Involve more participants in the discussion and get more feedback.
Dive deeper into the subject area and collect more real-life examples.

Now I understand this topic and maybe later I will have thoughts about what we can do. At first glance, it seems that we need to match the fields that are under the control of the helm ( managedFields: [ manager: helm ]), but it is worth considering more details and pitfalls.

[mumoshu]

@R-omk Thanks for the thoughtful response! I definitely hear you.

But I was more inclined to enhance helm-diff earlier with various options so that everyone can try and see which combinations of options work best for them, and hopefully share their experiences and more concrete feedback in this thread.
I thought it can be a more pragmatic approach, especially after seeing #176 took almost 2 years to progress.

Does that sound particularly wrong to you?

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.