-
Notifications
You must be signed in to change notification settings - Fork 40k
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
Support both "type":"any" and "type":"object" in kubectl validation #24309
Comments
This seems to have broken backwards compat.
node.yaml
kubectl version
|
Yes that should be fixed once we release 1.2.3 with #24104. Do you want us to rollback the change on HEAD until 1.2.3 is rolled out? |
cc @mikedanese |
cc @gmarek |
@nikhiljindal - what's the status of this? It seems that it blocks at least two other things. |
1.2.3 is released already so this should not be blocking anymore. Am keeping the issue open to track removing the workaround. |
Is there ever a time when If the answer is "yes", then we should be using |
Issues go stale after 30d of inactivity. Prevent issues from auto-closing with an If this issue is safe to close now please do so with Send feedback to sig-testing, kubernetes/test-infra and/or |
I think this is obsolete now with our move to OpenAPI (swagger 2.0). |
agreed |
We used to generate our swagger spec with "type":"any" for any type that wasnt supported in swagger (for ex: maps).
It was later pointed out that "type":"object" is the correct representation: #4700 (comment).
We have now moved to using "type":"object" in our swagger spec (which will be part of release 1.3), but for kubectl to work with old apiservers, we allow both "type":"object" and "type":"any" in kubectl validation code (#24054).
We cherrypicked that in release 1.2 (so that 1.2 kubectl can work with 1.3 apiserver).
We can stop supporting "type":"any" in release 1.4 (1.4 kubectl will not be able to work with 1.2 apiserver, which is fine since we support version skew of only 1).
Filing this issue to keep track.
cc @bgrant0607 @kubernetes/sig-api-machinery
The text was updated successfully, but these errors were encountered: