-
Notifications
You must be signed in to change notification settings - Fork 931
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
Remove get all entirely #1584
Comments
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 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. |
There are some limitation that you probably saw in this link and original PR of
I'm putting these for the next person who wants to take a look at this issue. |
I still have to say I do not understand the claim that "it's unclear how we would communicate it was deprecated". Kubernetes makes breaking changes all the time, there is a supported version skew between client and server versions, and users must read the changelog when upgrading their cluster. It seems like the responses in that thread are saying "we can literally never remove this for the rest of time", and I just do not understand how that could possibly be the case. |
I can tell you are frustrated that the original issue was closed, but I'm not sure opening another issue is the best way to communicate the problem. What is the specific change that you are asking for? If it is for You can see what I'm talking about if you run Notice below that only some resources belong to the "all" category (see the last column):
Does this help explain why If you really need the all behavior, I recommend checking out this plugin to see if it works for you: |
Is there a better way? Commenting on the original issue thread would not accomplish anything.
As was stated by a large number of people in the original issue thread, the ask is that
Yes, but that is not the question being asked. |
You could open a feature request issue calling for that outcome @raxod502-plaid. Consider a title such as: |
/remove-kind bug |
I don't see that the closure was done by mistake. #151 (comment) looks intentional. /priority awaiting-more-evidence |
The closure may have been "intentional" by the person who executed it, but issue reactions show that 132 people disagreed with that decision, and 0 people agreed with it. Also, it was (correctly) re-opened later upon request in #599 because the issue was not resolved. Anyway, I filed #1591 per your request to have a fourth issue tracking this problem. Let me know if anything else is required. |
@raxod502-plaid Due to backwards compatibility issues, I don't think we'll ever remove This issue is already open, why do you prefer to track this work in another #1591 issue?. |
I think this comment #1584 (comment) explains well about the issue and since we can't remove get all. I think, we can also close this issue as won't fix. |
I don't prefer that, in fact I think #1591 is a needless duplicate. The only reason I opened it is because @sftim specifically asked me to do so in #1584 (comment).
This does not make sense to me. Could you address #1584 (comment)? |
It's not really possible to "deprecate" the It's not like there is code in kubectl looking for a keyword of Therefore, this isn't even something kubectl can do, and it needs to be raised in the k/k repo for discussion there. I'm not sure which sig that would be, but it is not CLI. Arguing about it here will accomplish nothing. |
I think I see the problem. When statements like this have been made, what was actually meant has been: It's not really possible to "deprecate" the This issue probably could have been moved along a lot faster if somebody had mentioned before that it had been filed against the wrong tracker, as opposed to just saying "this is impossible", since it clearly isn't impossible to solve the problem. I've filed kubernetes/kubernetes#124538 and hopefully we can get the ball rolling after 7 years. |
Everyone here has tried to be helpful 🤷♂️ I'm going to go ahead and close this issue, since you now have opened the other one in k/k. |
/close not-planned |
This is another copy of #599 since the linked issue #151 was incorrectly closed again even though the issue is still an issue and nothing has been done to resolve it.
The text was updated successfully, but these errors were encountered: