Dangerous behaviour to not fail on -n <namespace> --all

[m0un10]

What happened:

I accidentally ran kubectl delete crd -n <namespace> --all. It deleted all of my CRDs and broke my cluster beyond repair.
It warned that the CRD isn't namespaced but it didn't fail.

What you expected to happen:

I expect if -n <namespace> --all is set that it should fail indicating that it's a namespaced resource as opposed to simply warning. The warning is useless when the deletion has already happened to everything. Seems like a modern and more dangerous equivalent of rm -rf $unsetvar/ but more preventable.

How to reproduce it (as minimally and precisely as possible):

kubectl delete crd -n <namespace> --all

Anything else we need to know?:

Environment:

• Kubernetes client and server versions (use kubectl version):
• Cloud provider or hardware configuration:
• OS (e.g: cat /etc/os-release):

[k8s-ci-robot]

@m0un10: This issue is currently awaiting triage.

SIG CLI takes a lead on issue triage for this repo, but any Kubernetes member can accept issues by applying the triage/accepted label.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[brianpursley]

This seems like a similar failure mode as prune (kubernetes/kubernetes#110905)

There are probably a few cases where this might happen:

1. The one @m0un10 mentioned in this issue: kubectl delete crd -n something --all
2. You're trying to delete a single cluster-scoped resource: kubectl delete crd mycrd -n something
3. You delete from a file(s) (-f or -k) and specify a namespace, but the file contains cluster-scoped resources: kubectl delete -f mycrd.yaml -n something

As @m0un10 said, it does print a warning saying deleting cluster-scoped resources, not scoped to the provided namespace, but continues to perform the deletion.
https://github.com/kubernetes/kubernetes/blob/b7e82ad2fd03b23b53ab94de66c5b3c30863724a/staging/src/k8s.io/kubectl/pkg/cmd/delete/delete.go#L321

@KnVerey thoughts on this? Should this be handled in a way similar to pruning cluster-scoped resources?

[KnVerey]

I agree with you on the conceptual similarities, but unlike pruning (which is an alpha flag), kubectl delete is a GA command. This has actually come up many times before, and the SIG has concluded that we cannot just change this, as it would be a breaking behaviour difference. For more context, see this long thread and this closed KEP. This could be something we address through kuberc.

Duplicate of #1056 and many others linked from the mailing list thread.

cc @eddiezane

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale