Proposal: remove anchor finalizers as soon as subns starts getting deleted #200
Description
Today, if you delete a subnamespace anchor, the anchor is not fully deleted until the underlying subnamespace is deleted. Namespaces are usually deleted within several seconds, but can sometimes get "stuck," in which case the anchor isn't deleted either.
This behaviour has two problems:
- If the anchor isn't deleted, it can prevent the parent namespace from being deleted, since namespaces cannot be deleted until all the objects in them have also been deleted.
- The code used to implement this behaviour in HNC is quite complicated, and changing it may introduce subtle bugs.
As a result, we're proposing a simplification: HNC will let the anchor be deleted as soon as it starts deleting the subnamespace. This means that the anchor will typically vanish virtually "instantly" - that is, typically less than a second after you say kubectl delete subns <foo>. The subnamespace itself will be put into the "deleting" state and will be removed whenever Kubernetes is able to do so.
If you've never checked to see if an anchor has actually been deleted before, this change won't affect you. Otherwise, you need to be aware that simply because the anchor has disappeared, there's a chance that the underlying namespace could still be there, either because it's still being deleted, or because it's gotten stuck somehow.