Proposed change for HNC v1.1: faster anchor deletion

[Adrian Ludwin]

Hi all, we're considering making a change in the next version of HNC v1.1 and wanted to know if it would affect anyone.

TL;DR: we are proposing that subnamespace anchors will be removed immediately when deleted by users, even if the underlying subnamespace has not been fully removed (GH issue).

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.

If you have any concerns about this change, please reach out to us by commenting on issue 200.

Thanks, Adrian