k3kcli cluster delete should error/warn when the namespace is not provided not mislead with 'deleting' message

Environmental Info: Host Cluster Version:

v1.33.5+rke2r1

Node(s) CPU architecture, OS, and Version:

Host Cluster Configuration:

1 server - Ubuntu OS. K3K Cluster Configuration:

Describe the bug:

$ k3kcli cluster delete k3kcluster
INFO[0000] Deleting [k3kcluster] cluster in namespace [k3k-k3kcluster]

says it is going to delete the cluster. But the cluster still remains listed:

$ k3kcli cluster list
NAMESPACE    NAME         MODE      STATUS   POLICY
k3k-system   k3kcluster   virtual   Ready    <none>

We need to provide the namespace that k3k was installed in the host cluster - for it to be able to delete the same. This is misleading that it is going to delete something with a namespace 'k3k-k3kcluster'. There is no warning which namespace is a needed info.

The original delete command should warn/error out if we do not provide the namespace. At least mention nothing found to delete in the namespace. Namespace should be considered mandatory information needed.

it works if we do this of course:

$ k3kcli cluster delete k3kcluster -n k3k-system
INFO[0000] Deleting [k3kcluster] cluster in namespace [k3k-system]
:~$ k3kcli cluster list

Steps To Reproduce:

• Created a cluster with k3k create:
• Delete cluster without providing namespace: k3kcli cluster delete k3kcluster

Expected behavior:

The original delete command should error out if we do not provide the namespace - (at least saying no cluster found in assumed default namespace or something..) Ex:

No cluster resource found in namespace k3k-k3kcluster.

Additional warning message to consider:

Please provide the correct namespace from `k3kcli cluster list` for `k3kcli cluster delete` command. 

It should definitely not say 'deleting' when it found nothing to delete.

Actual behavior:

the delete command says it is deleting, but the cluster still remains listed at the end. Appears to do nothing and there is no warning to the user as to what actually happened.

Additional context / logs: