HNC: consider making leaf subnamespace deletion easier

[adrianludwin]

Right now, to delete a subnamespace, you first have to set allowCascadingDelete on the subnamespace itself (or its parent). This makes subnamespaces harder to delete than regular namespaces, which have no such protection.

The goal of allowCascadingDelete was really to prevent cascading deletions - that is, unintentionally deleting multiple namespaces. I wonder if we could skip this check unless the namespace being deleted actually has subnamespaces itself. So for example, I could say:

k hns create sub -n parent
k delete subns sub -n parent

But not:

k hns create sub -n parent
k hns create subsub -n sub
k delete subns sub -n parent # fails because of subsub

[adrianludwin]

/assign @yiqigao217

This is on the HNC backlog so it's not immediately urgent (e.g. it's not for v0.4)

[yiqigao217]

@adrianludwin WDYT if we also add webhook rules on denying delete namespace when it has children, since otherwise the children will be orphaned and they will have "parentMissing" condition, which is a condition that's easy to get since we dont have any webhook on that.

[rcolline]

(edited)

The issue here is that namespaces are cluster level resources so deleting and creating them requires cluster level permissions.

We use a proxy resource in the parent namespace (an "anchor", I think) to represent the child namespaces.

One option I thought of is to create a couple of resource bound roles for each namespace created by HNC. HNC can maintain the role bindings to these role based on RBAC permissions to the anchor resource.

With this, now deleting, updating and reading namespaces is fully natural.

Thoughts?

[adrianludwin]

Discussed the rationale behind subnamespaces offline. We considered an alternative where the "SubnamespaceAnchor" becomes vestigial after the namespace is first created, and HNC create ClusterRoles and ClusterRoleBindings for the newly created child namespace (basically copying permissions from the SubnamespaceAnchor to the namespace). This means that the namespace can then be deleted via `k delete ns child` instead of `k delete subns child -n parent`. I hadn't considered this before so it's an interesting decision to write down. We agreed that this change isn't essential today (even if we agreed to make it) and we'll watch for signs that we should switch to this kind of scheme in the future.

…

On Thu, Jun 4, 2020 at 2:09 PM Ray Colline ***@***.***> wrote: Can we just treat all namespaces the same. If you have namespace DELETE privilege on the namespace you can delete it. What is driving the need to treat HNC namespaces different? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#716 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AE43PZEINRQQNIWW7UCZKJLRU7PMPANCNFSM4M76VUFA> .

[akessner]

ubnamespaces offline. We considered an alternative where the "SubnamespaceAnchor" becomes vestigial after the namespace is first created, and HNC create ClusterRoles and ClusterRoleBindings for the newly created child namespace (basically copying permissions from the SubnamespaceAnchor to the namespace). This means that the namespace can then be deleted via k delete ns child instead of k delete subns child -n parent. I hadn't considered this before so it's an interesting decision to write down. We agreed that this change isn't essential today (even if we agreed to make it) and we'll watch for signs that we should switch to this kind of scheme in the future.
…

We are having trouble with ArgoCD removing namespaces.
Was this new approach ever used?