tk delete trashes entire namespace, not just resources it created/managed

[24601]

This is very destructive and non-standard behavior in terms of k8s devops tools.

It is not uncommon for namespaces to have resources in them from a variety of tools, and tk should really only delete what it created/manages by default, and should be very, very clear that it is going to trash everything, not just its owned resources, especially when it did not create the ns (which is slightly more reasonable, but still a huge gaping data loss probability).

It seems this was mentioned 2 yrs ago in #311, but the warning actually just ends up at the top and usually not in your terminal after all the diffs get listed.

This is very, very divergent behavior from best practices, even experienced, seasoned sysadmins/ops folks will be bitten by this.

Even though this kind of behavior is, IMHO, an anti-pattern (that's being nice :)), if it wants to be retained as part of the tanka system design, maybe rename the command tk decimate-ns or something (not joking) and keep tk delete consistent with best practices.

We only blew away an NS on our dev cluster, so no big deal, CD just rebuilds it and every properly architected platform should recover from this easily, but this is a disaster waiting to happen for someone (and likely already has been), and why (esp unnecessarily) create ambiguous, non-standard, and non-convention-leveraging destructive tools? I can't think of a good reason.

[kingindanord]

yea, today is the second time I blew a complete monitoring namespace where most of resources managed by helm. I did it once with tk delete but surprisingly today I did it with tk prune.

[zerok]

Do you have the namespace created as part of your environment? I tried delete without a managed namespace and it only deleted the resources it had created.