Proposal: support destruction of mutatingwebhookconfiguration + secret during delete

[drnic]

Currently the instructions for installation of an eirinix extension needs to include explicit Tear it down instructions because the webook generates a mutatingwebhookconfiguration and a secret.

Could we have these two things automatically cleaned up during destruction of the webhook deployment? Or once created, they'll always be a manual cleanup task?

/cc @mudler

[mudler]

Sorry for the late reply - I wanted to come back at you with an implementation but I couldn't find the time yet. Yes I totally agree with you, there should be at least a Cleanup method that the Manager exposes to tear down the extension data (mutatingwebhooks, secrets).

There is extra care needed in automating the cleanup, it is very tricky to detect when is the correct moment to clean it up, as you might not always want to re-generate all the extensions certs each time you turn it down (e.g. you could register it in a process, and have a separate pod executing it, with lower privileges).

I would be more inclined indeed to expose a manual Cleanup() that the Developer knows when to call.

[drnic]

Thought experiment: what if the helm chart included empty/noop versions of generated resources (webhooks, secrets), and the running code now updates these resources rather than creating them.

That would allow “helm delete” to know about them and delete them.

Now that I’ve written that idea out - it might be blocked by resources or their fields that cannot be modified.

[drnic]

Ooh perhaps helm 3 might make “helm delete” able to delete resources even if they weren’t in the original chart installation - perhaps if our generated webhook resource includes the correct labels then “helm delete kubecf” will pick up and delete the generated resources too?