Open sauravmndl opened 10 months ago
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.
@ardaguclu Please don't close this without analysis. It is not a duplicate ask of https://github.com/kubernetes/kubectl/issues/1485
Sorry, you are right, it seems that this is slightly different than the other. Basically, your request is about enriching https://github.com/kubernetes/kubernetes/blob/d61cbac69aae97db1839bd2e0e86d68f26b353a7/staging/src/k8s.io/kubectl/pkg/cmd/get/get.go#L565 based on the filtered condition. There might be some side effects and possible questions with respect to this;
The Kubernetes project currently lacks enough contributors to adequately respond to all issues.
This bot triages un-triaged issues according to the following rules:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/remove-lifecycle stale
/close
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.
This bot triages un-triaged issues according to the following rules:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/remove-lifecycle rotten
/close
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle rotten
Sorry, you are right, it seems that this is slightly different than the other. Basically, your request is about enriching https://github.com/kubernetes/kubernetes/blob/d61cbac69aae97db1839bd2e0e86d68f26b353a7/staging/src/k8s.io/kubectl/pkg/cmd/get/get.go#L565 based on the filtered condition. There might be some side effects and possible questions with respect to this;
- What will be the output for filtered but not namespaced resources?
- What if user filters in namespace but resource doesn't exist not only in filtered domain, but also in that namespace. What would be the expected output?
I agree with the questions, also there can be many more . I think if we put filters on we already expect the list as per our condition so output is technically right "No resources found" for our search i.e. using filters. this is same condition as when we search for pods in one namespace and get 0
however its not that cluster doesn't have pods , its just the result as per our search.
I guess the person searching for pods as per conditions will understand the result anyways.
What would you like to be added:
Why is this needed: What would you like to be added: when execute some command like this with filter kubectl get pods -n mynamesapce --field-selector status.phase=Pending -o wide
and returns no output like
No resources found in mynamesapce namespace.
This indicates nothing found in the namesapce. But actually with provided filter no resource found. Resources are there.
Why is this needed:
Message like this will be better No resources found in mynamesapce namespace with applied filter. or No resources found in mynamesapce namespace with applied conditions. If it is specific for namespace in mynamesapce namespace. then should clearly call out with condition/filter.