-
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
Hide groups with new versions from old kubectl #35840
Hide groups with new versions from old kubectl #35840
Conversation
Jenkins GCE Node e2e failed for commit 03c281e. Full PR test history. The magic incantation to run this job again is |
@k8s-bot node e2e test this |
@@ -429,6 +430,43 @@ func (s *GenericAPIServer) newAPIGroupVersion(apiGroupInfo *APIGroupInfo, groupV | |||
}, nil | |||
} | |||
|
|||
// TODO: Remove in 1.6. Returns if kubectl is older than v1.5.0 | |||
func isOldKubectl(userAgent string) bool { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not in genericapiserver, please. This only applies to the master, so make the surface area here as small as possible
03c281e
to
586a170
Compare
Moved to apiserver. PTAL. Thanks. |
Jenkins verification failed for commit 586a170. Full PR test history. The magic incantation to run this job again is |
"time" | ||
|
||
"k8s.io/client-go/pkg/util/sets" | ||
"k8s.io/client-go/pkg/version" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's unfortunate goimports finds common types in the client-go pkg first. I think we want our own sets type
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same for the version util
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Eh..I'm using goimports locally and I guess it imports based on alphabetical order.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I anticipate that creeping in a lot of places after client-go is added :-/
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes. I think these kind of utility packages should be moved to their own repo, then there will be only one copy of them.
586a170
to
a545ac7
Compare
@liggitt @smarterclayton merging this PR will unblock two 1.5 PRs for moving StatefulSet to beta (#35731) and DisruptionBudget to beta (#35567) |
|
||
// TODO: Remove in 1.6. This is for backward compatibility with 1.4 kubectl. | ||
// See https://github.com/kubernetes/kubernetes/issues/35791 | ||
var groupsWithNewVersionsIn1_5 = sets.NewString("apps", "policy") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
both of these groups existed in 1.4... we're completely hiding the groups from the discovery doc? won't that break old kubectl if someone tries to create anything in those groups?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The alpha version of the two groups will be removed in 1.5, so 1.4 kubectl won't work for these groups with an 1.5 apiserver anyway.
@smarterclayton @liggitt could you take a look? Thanks. |
seems ok. can you queue up the revert to merge once the 1.5 branch is cut? |
Do you mean revert in 1.6? |
yes, which I guess is right after the 1.5 branch is done fast-forwarding master, right? |
Right. Created #36004. |
If there is no more comment I'll apply the label. It's blocking two 1.5 PRs. |
Yes, presumably those PRs block other 1.5 PRs also. Would love to see this one merged ASAP. |
Automatic merge from submit-queue |
IMO this is a client bug. I guess changing the server is an OK temporary fix, but the client should also change to tolerate collisions like this, so that we don't ever need any more server bandaids. |
#36898 is the client-side fix. It's merged. |
Oh, awesome! |
I agree. I fixed it client-side shortly before release.
…On Tue, Dec 6, 2016 at 4:39 PM, Daniel Smith ***@***.***> wrote:
IMO this is a client bug. I guess changing the server is an OK temporary
fix, but the client should also change to tolerate collisions like this, so
that we don't ever need any more server bandaids.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#35840 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AH2BSp324rsT8T01qZSWQFlnnrzeofciks5rFdYOgaJpZM4Kj9_p>
.
|
Fix #35791
What caused the bug?
In 1.5, we are going to graduate Policy and Apps to beta. Old version kubectl doesn't has the new versions built-in, its TRP dynamic discover thinks Policy/v1beta1 is a TPR, and tried to register it in kubectl's scheme. The registration failed because Policy group already exist, because kubectl had registered Policy.v1alpha1.
How does this PR fix the bug?
This PR let the API server hides Policy and Apps from old version kubectl, so TPR discovery won't see them.
Old version kubectl doesn't know about Policy/v1beta1 or Apps/v1beta1, and v1alpha1 will be removed, so old version kubectl won't work for Policy or Apps anyway, so this PR does not cause any function loss.
@kubernetes/sig-api-machinery @liggitt @smarterclayton @deads2k @janetkuo @mwielgus
This change is