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
Warn users about CRD alias naming conflicts #108573
Comments
@ciberkleid: This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the The 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. |
/sig cli |
/kind bug |
Could you please paste |
Results of
|
@ciberkleid Could you please explain me this statement of yours -
Especially more than one type part. Do you mean there can be another resource but of different type with name img, and there are no restrictions on aliases to make them unique from the name of other resources ? |
In this example, the types would be I am not sure how restricting aliases would work (would it be a bug in kpack or knative? would it be an operator decision on a per-cluster basis? both have their drawbacks...). However it is implemented, at the very minimum, if nothing else changes, the current result of |
@ciberkleid @pacoxu So we have to add a warning in the logs when we face this situation like - But where the code is written for this log. When I did |
@pacoxu @ciberkleid I think we have to update the statement which is printed here |
/assign |
Worth adding that this is relevant to multiple verbs (get, delete, describe, create, patch, edit, set, diff... others?), and that a warning message is probably sufficient as any other change would break backwards compatibility. cc @stealthybox @NikhilSharmaWe Thanks for giving it a shot! I think more conditional logic is required, as well as a separate warning message, but I don't personally have the expertise to know how to solve this, so I will defer to the maintainers. |
This is not a bug, this is working as designed. I do understand that this is causing a lot of confusion, but in your case the problem is not with |
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:
You can:
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 and PRs. This bot triages issues and PRs according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle rotten |
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /close |
@k8s-triage-robot: Closing this issue. In response to this:
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. |
/reopen |
@ardaguclu: Reopened this issue. In response to this:
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. |
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. This bot triages issues according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /close not-planned |
@k8s-triage-robot: Closing this issue, marking it as "Not Planned". In response to this:
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. |
/reopen |
@ardaguclu: Reopened this issue. In response to this:
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. |
/remove-lifecycle rotten |
Chiming in to second the described behavior being a problem. An especially troublesome case is with the
That may be the intended behavior, but I was also surprised that the client was willing to delete something when the name was ambiguous. |
Issue #94860 was closed as stale so opening a new one.
Another case in which this happens is with
kubectl get img
if both Knative Serving and kpack are installed.Calling
kubectl api-resources
shows that a kpack Image resource should have four aliases:Three of these aliases work:
However, one of the aliases (
img
) does not work:I think it is important to inform the user that the
img
resource may refer to more than one type. The above results are misleading and can cause users to draw incorrect conclusions about what is or isn't running.Aside: I had originally logged this under
kpack
but was advised that it is akubectl
issues, hence bringing it up here. For reference, thekpack
issue is buildpacks-community/kpack#929.Originally posted by @ciberkleid in #94860 (comment)
The text was updated successfully, but these errors were encountered: