Is it possible to disable the diff feature ?

[mtparet]

Question

We have oversize issues with helm release as the diff storage is duplicating the whole data and the data is already big. I checked the documentation but it seems we cannot disable this feature, could you confirm this ? If this is case, what do you think about adding this possibility ? We like to configure this on ressources the same way we configure handlers so we can choose when to enable it or not.

Checklist

• [x] I have read the documentation and searched there for the problem
• [x] I have searched in the GitHub Issues for similar questions

Keywords

diffbase diff storage

[nolar]

Diffbase is stored only when there is need for that — i.e. when on.create/update/delete/resume handlers exist for the resource kind. With on.event/index/timers/daemons, diffbase is not stored.

The existence of diffbase is currently weaved into Kopf’s design conceptually and architecturally — so that it cannot be removed. The diffs are actually a side-effect; the main purpose of diffbases is to detect if there are any essential changes worth reacting.

However, you can implement your own diffbase storage (and progress storage too, separately, if needed), and persist the data elsewhere, e.g. in redis or on a file system or postgres — anything that is persistent. Also, you can clean and/or gzip the stored content there.

In particular, you can inherit from the existing AnnotationsDiffBaseStorage and redefine the “build()” method (or is it “clean()”? I forgot.) — and wipe all unnecessary fields of helm — in addition to what Kopf already wipes from there (all the metadata except labels&annotations). The operator will become blind to these fields’ changes then.

[OmegaVVeapon]

Sorry for jumping in, was following this discussion with interest and just wanted to make sure I understood something.

We're talking about the kopf.zalando.org/last-handled-configuration annotation that kopf adds to handle change detection here, is that correct?

And the conclusion is that if we're using:

• on.create
• on.delete
• on.update
• on.resume

handlers, then we need this annotation and we shouldn't remove it?

Because removing it cause negate kopf's ability to act on the state-changing handlers listed above.

Did I get that right? Because that annotation is also causing a tiny issue for us 😅

[nolar]

Correct, with notes.

"Correct": Kubernetes has no such feature with change detection and new-vs-old object distinction. Kubernetes capabilities end with @kopf.on.event() low-level handlers. The change detection is Kopf's own addon, so are handlers with retries and delays. Kopf relies on these "diffbases", their existence/absence, and their content. For example, if the annotation is deleted, it would be treated as a creation of a new resource.

"With notes": Using annotations is Kopf's default behaviour to make it work out of the box for most cases. Kopf uses Kubernetes and annotations as a "database" for its own state persistence. You can move the state to the .status stanza, but that only works for properly configured CRDs (x-kubernetes-preserve-unknown-fields: true), not for builtins (pods&co). The state can be persisted anywhere else, as long as you have 2 methods implemented: fetch() and store() (link, sample implementations are also there below).

So, diffbase persistence is needed, but it does not necessarily and unavoidably have to be done via annotations.

• https://kopf.readthedocs.io/en/stable/configuration/#change-detection