Add warning to docs about finalizers. about kopf HOT 7 CLOSED

No rush on this.

What I have done is gone back to our training system and modify it so that after having deleted the temporary namespace used for the demo/workshop, that on the next cycle of checking for namespaces that need to be deleted, if it finds that it is in terminating state, it will go through objects still in the namespace and if it sees any with a deletion timestamp, indicating in process of being deleted, and a list of finalizers, it will delete the finalizers to try and unstick things. We need this regardless as a way of recovering since also seeing this problem with some other mainstream operators.

Once have cleaned some things up and got even a skeleton of a demo going with kopf operator example, will drop you a link so you can see what this training system is I am talking about.

from kopf.

@GrahamDumpleton Good point, thanks.

There is a related issue: #24 — this might help to design the operators without these blocks. However, the default behaviour will be to add the finalizers (at least when the delete-handlers are present), so the namespace deletion will be blocked.

A doc page on the manual resource un-blocking and deletion (or maybe a "Troubleshooting" page) seems the only solution.

It is interesting to learn how other operators/controllers handle this problem of finalizers.

from kopf.

FWIW, in my test case, which I am only really using at this point in training material to explain operators to people, the CRD object is used as the owner for everything created as a result of it being created. Thus when the CRD object is deleted, all those resource objects are in turn deleted.

So for my example I don't need an explicit deletion action in the operator to clean up anything. Thus, being able to disable the addition of the finalizer as described in the separate issue would be a reasonable solution.

I might as a fiddle for now patch the CRD to remove the finalizer in the create handler. The training environment I am using relies on creating temporary namespaces for users to work in, so right now I am getting lots of terminating namespaces hanging around.

from kopf.

@GrahamDumpleton I see. Let's roughly estimate that I can add the finalizers' optionality this or next week; but no promises.

As a quick work-around, indeed, I already used the manual patching some time ago:

kubectl patch kopfexample myobj -p '{"metadata": {"finalizers": []}}'

By the way, the owner references are supported by Kopf with some additional magic, which is usually expected (e.g. labelling & auto-naming of children) — see Hierarchies & Cascaded deletions — e.g. via kopf.adopt().

from kopf.

Is there a reason trying to apply a patch via a REST API call in the create handler, to delete the finalizer, would have no effect? The same patch can add extra labels, or add extra items to the list of finalizers, but I can't seem to delete the kopf finalizer that was there already. I am ensuring I am using a merge patch and not strategic, so it should replace what is there for the list.

Separately, if I run kubectl get -w on the resource type when doing same patch using kubectl patch --type merge, it shows two state changes. So it almost looks like I delete it and then the operator is changing it back. Is that possible?

from kopf.

In fact, if I delete the operator and then do the same patch with kubectl patch --type merge, then it does work, with it being remove, and there was only one state change. So definitely looks like the operator overrides it and adds it back.

from kopf.

@GrahamDumpleton Sorry, I probably didn't get the flow that you use.

But yes, the operator adds the finalizer every time it sees a new object: "new" means that there is no Kopf's finalizer. So, if you somehow remove it, and the operator is running at the moment, this change is immediately noticed, triggers the reaction cycle, and the finalizer is re-added as the first step (because Kopf believes this is a new object).

It is interesting to consider another logic here: if the operators sees an event on an object with no finalizer, but with the "last-seen" annotation (which means this object was known to the operator before), then avoid re-adding the finalizer again.

This would allow to remove the finalizer at will as part of the creation handler.
But this is efficiently an equivalent to not adding the finalizer by explicitly specifying so (#24).

Let me think on this tomorrow. I suppose, since most of the huge refactoring PRs are merged (only one is left by now), this can be done easily in few lines of code.

PS: I have also added a troubleshooting section with this problem (see #83 , preview).

from kopf.