-
Notifications
You must be signed in to change notification settings - Fork 39.8k
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
Preserve API group order in discovery, prefer extensions over apps #43553
Conversation
d88361a
to
8fab539
Compare
8fab539
to
c36421d
Compare
} | ||
sort.Strings(groupNames) | ||
for _, groupName := range groupNames { | ||
for _, groupName := range s.apiGroupNamesForDiscovery { |
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.
Consider adding a comment that this maintains the insertion 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.
comment added
/lgtm |
@bgrant0607 @lavalamp @wojtek-t could you PTAL at this release blocker? |
@pwittrock @ymqytw wasn't sure if you wanted a release note on this PR or if you were planning to add them in manually... feel free to edit or remove the one I put in the description |
@deads2k would like your take on how (or if) you see this interacting with the 1.7 registration stuff you have in progress (or if the aggregator bypasses this) |
It will be ok. Minor fitting pains, but nothing severe. |
lgtm |
c36421d
to
707f0fb
Compare
added comment, retagging |
lgtm |
@liggitt Updated the release note to be focussed on what to expect when upgrading a cluster from 1.5 -> 1.6 |
sort.Strings(groupNames) | ||
for _, groupName := range groupNames { | ||
|
||
// ranging over apiGroupNamesForDiscovery preserves the registration 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.
Please document that the order is preserved in the function description, also.
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.
+1 Add a godoc to AddAPIGroupForDiscovery that the call order is significant.
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.
opened #43623 with doc
I like this much better, thanks. One minor comment. Given the time crunch, I'm ok with it not being addressed. /approve |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: bgrant0607, liggitt, pwittrock
Needs approval from an approver in each of these OWNERS Files:
You can indicate your approval by writing |
will open a follow up with additional godoc once master reopens |
ref #43542 |
Thanks, @liggitt |
Yeah, thanks, this is much better. |
Automatic merge from submit-queue |
@liggitt PR needs rebase |
Due to backwards compatibility issues (kubernetes#42392) introduced in 1.6 when adding new API group we've set extensions to be preferred group over apps (kubernetes#43553). Now that extensions is entirely deprecated it's time to revert this change and prefer correct API groups.
Fixes #42392, supercedes #43543
Kubectl 1.5 still uses compiled in types in kubectl edit and apply.
Because kubectl 1.5 does not have the apps/v1beta1/deployment resource compiled in, the preferred group order must have extensions come before apps. The preference order is determined by the order that the groups are listed by the discovery service, with the first elements preferred over the last elements.
This PR:
apps
group to the end of the list (for the same result as Prefer extensions group over apps group in Kubernetes 1.6. #43543)This has the side benefit of making all TPR API groups (regardless of group name) come after the core API groups, instead of potentially appearing earlier in discovery order