Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Include Namespace in kubectl delete Dry-Run Output #1621

Open
totegamma opened this issue Jul 8, 2024 · 7 comments · May be fixed by kubernetes/kubernetes#126626 or kubernetes/kubernetes#126619
Open
Assignees
Labels
good first issue Denotes an issue ready for a new contributor, according to the "help wanted" guidelines. help wanted Denotes an issue that needs help from a contributor. Must meet "help wanted" guidelines. kind/feature Categorizes issue or PR as related to a new feature. triage/accepted Indicates an issue or PR is ready to be actively worked on.

Comments

@totegamma
Copy link

totegamma commented Jul 8, 2024

What would you like to be added:

Prefix namespace to kubectl delete dry-run result.

current:

$ kubectl delete -f ... --dry-run=server
deployment.apps "myapp" deleted (server dry run)
$

proposed:

$ kubectl delete -f ... --dry-run=server
myapp-namespace deployment.apps "myapp" deleted (server dry run)
$

Why is this needed:

The current output is ambiguous, as the resource name should be identifiable as unique.

When working with multiple namespaces like "myapp-prod" and "myapp-dev", and intending to tear down some resources in "myapp-dev", the command might look like this:

$ kustomize build . | kubectl delete -f - --dry-run=server
deployment.apps "kube-prometheus-stack-kube-state-metrics" deleted (server dry run)
$

From this output, it's unclear whether the manifest targets "myapp-dev" or "myapp-prod". This ambiguity requires additional checks to ensure the correct namespace is being targeted.

Printing the namespace in the dry-run output would enhance clarity and confidence in identifying the targeted resources.

Other considerations
This change can be applied for other operations like apply and replace. However, non-delete operations can be validate with the "diff" command.
Therefore, I think it is acceptable to add this feature only for the delete operation.

sample implementation would be like this: totegamma/kubernetes@65c1881

If this issue accepted, I want to get assigned and make a PR.

@totegamma totegamma added the kind/feature Categorizes issue or PR as related to a new feature. label Jul 8, 2024
@k8s-ci-robot k8s-ci-robot added the needs-triage Indicates an issue or PR lacks a `triage/foo` label and requires one. label Jul 8, 2024
@Ritikaa96
Copy link
Contributor

Hi @totegamma , The dry run in fact checks the namespace, it is just not notified in output ,If you try to delete a pod which exist in other namespace the error will come out right . Adding namespace like
pod <name> (ns) deleted (server dry run)
may add more clarity. however the developers usually knows that lil detail already.

@totegamma
Copy link
Author

Hello @Ritikaa96,

Thank you for your reply.

Yes, I know there are no problems with the internal mechanism. I just want to notify the namespace in the output for clarity. Hiding the namespace is a little unkind.

When the applied manifest is too big, it is hard to grasp all resources. This often happens when we use generators such as Helm charts or Kustomize. We can check the manifest with other commands such as grep, but since kubectl already has a dry-run mode, it would be nice to print the namespace for clarity.

@mpuckett159
Copy link
Contributor

/triage accepted
/good-first-issue

@k8s-ci-robot
Copy link
Contributor

@mpuckett159:
This request has been marked as suitable for new contributors.

Guidelines

Please ensure that the issue body includes answers to the following questions:

  • Why are we solving this issue?
  • To address this issue, are there any code changes? If there are code changes, what needs to be done in the code and what places can the assignee treat as reference points?
  • Does this issue have zero to low barrier of entry?
  • How can the assignee reach out to you for help?

For more details on the requirements of such an issue, please see here and ensure that they are met.

If this request no longer meets these requirements, the label can be removed
by commenting with the /remove-good-first-issue command.

In response to this:

/triage accepted
/good-first-issue

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-sigs/prow repository.

@k8s-ci-robot k8s-ci-robot added good first issue Denotes an issue ready for a new contributor, according to the "help wanted" guidelines. triage/accepted Indicates an issue or PR is ready to be actively worked on. help wanted Denotes an issue that needs help from a contributor. Must meet "help wanted" guidelines. and removed needs-triage Indicates an issue or PR lacks a `triage/foo` label and requires one. labels Jul 17, 2024
@totegamma
Copy link
Author

/assign

@rezkam
Copy link

rezkam commented Aug 5, 2024

@totegamma Have you started working on it, or do you still plan to? If not, I'd love to take a crack at it, as it looks like a great first issue.

Thanks

@totegamma
Copy link
Author

@rezkam
Thanks for checking in! I’ve just finished up a busy task and was about to start working on this issue. If anything changes, I’ll let you know.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
good first issue Denotes an issue ready for a new contributor, according to the "help wanted" guidelines. help wanted Denotes an issue that needs help from a contributor. Must meet "help wanted" guidelines. kind/feature Categorizes issue or PR as related to a new feature. triage/accepted Indicates an issue or PR is ready to be actively worked on.
Projects
None yet
5 participants