-
Notifications
You must be signed in to change notification settings - Fork 39.6k
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
Include unavailable apiservices in discovery response #66932
Include unavailable apiservices in discovery response #66932
Conversation
/assign @liggitt |
/sig api-machinery |
/kind bug |
/ok-to-test |
/assign @cheftako |
e3fead4
to
3bc4782
Compare
b6cfd02
to
9c381cf
Compare
t.Fatal(err) | ||
} | ||
_, err = aggregatorDiscoveryClient.Discovery().ServerResources() | ||
assertWardleUnavailableDiscoveryError(t, err) |
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 wardle APIService
was never available, because Service
object is missing, which is referenced in the APIService
object above:
Service: &apiregistrationv1beta1.ServiceReference{
Namespace: "kube-wardle",
Name: "api",
},
Kube-aggregator previously silently skipped unavailable API services in the /apis
endpoint. With the new change, there is an error with details that are asserted in the assertWardleUnavailableDiscoveryError
function (since .Discovery().ServerResources()
now invokes /apis/wardle.k8s.io/v1alpha1
endpoint that returns 503
error).
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 think it's good to verify this error this way to make sure discovery reports it is incomplete in this case. once we verify this way, can we create the service pointing at 127.0.0.1:<wardlePort>
and make sure we get a successful discovery?
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.
actually, I'm not sure we have the network infrastructure here to use services
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.
heh, your initial suggestion made me wonder if there was some magic trick to make such Service
|
||
// TODO figure out how to turn on enough of services and dns to run more | ||
} | ||
|
||
func assertWardleUnavailableDiscoveryError(t *testing.T, err error) { | ||
if err == nil { |
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.
call t.Helper()
at the top of this method to make sure failures report the line number where this was called
if err != nil { | ||
t.Fatal(err) | ||
} | ||
assertWardleUnavailableDiscoveryError(t, err) |
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.
should be able to drop this if we create a Service object above
this looks good to me, just the one comment on updating the integration test to test discovery in both failure and success cases, then squash down |
this looks good to me as-is. the aggregated e2e test exercises successful end-to-end discovery and aggregation cases more thoroughly, and the integration test change here ensures discovery functions appropriately in failure cases. can you squash this down, then I'll LGTM |
@liggitt awesome, will let you know when I squash this PR. |
780f11e
to
d4690f4
Compare
@liggitt commits squashed, please LGTM. |
/lgtm |
surprisingly painless. /lgtm |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: deads2k, liggitt, nilebox The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Automatic merge from submit-queue (batch tested with PRs 66394, 66888, 66932). If you want to cherry-pick this change to another branch, please follow the instructions here. |
@liggitt can you cherry-pick this change to k8s 1.11 branch please? We need it to fix the issue kubernetes-retired/service-catalog#2254 |
Automatic merge from submit-queue (batch tested with PRs 67294, 67320, 67335, 67334, 67325). If you want to cherry-pick this change to another branch, please follow the instructions <a href="https://github.com/kubernetes/community/blob/master/contributors/devel/cherry-picks.md">here</a>. Add wait to discovery integration test to fix flakiness **What this PR does / why we need it**: Reduce the flakiness of the discovery test that was introduced in #66932 (see cherry-pick PR #67154 for report on flaky failure and suggestions). **Which issue(s) this PR fixes** *(optional, in `fixes #<issue number>(, fixes #<issue_number>, ...)` format, will close the issue(s) when PR gets merged)*: Fixes # **Special notes for your reviewer**: **Release note**: ```release-note NONE ```
…2-upstream-release-1.10 Automatic merge from submit-queue. Automated cherry pick of #66932 #67433: Include unavailable API services in discovery response, allow failed discovery on initial quota controller start Cherry pick of #66932 on release-1.10. #66932: Include unavailable API services in discovery response #67433: allow failed discovery on initial quota controller start ```release-note kube-apiserver now includes all registered API groups in discovery, including registered extension API group/versions for unavailable extension API servers. kube-controller-manager can now start the quota controller when discovery results can only be partially determined. ```
…2-upstream-release-1.11 Automatic merge from submit-queue. Automated cherry pick of #66932 #67433: Include unavailable API services in discovery response, allow failed discovery on initial quota controller start Cherry pick of #66932 #67433 on release-1.11. #66932: Include unavailable API services in discovery response #67433: allow failed discovery on initial quota controller start ```release-note kube-apiserver now includes all registered API groups in discovery, including registered extension API group/versions for unavailable extension API servers. kube-controller-manager can now start the quota controller when discovery results can only be partially determined. ```
What this PR does / why we need it:
Include unavailable apiservices into
apis/
discovery endpoint response to fix namespace deletion kubernetes-retired/service-catalog#2254Which issue(s) this PR fixes (optional, in
fixes #<issue number>(, fixes #<issue_number>, ...)
format, will close the issue(s) when PR gets merged):Fixes kubernetes-retired/service-catalog#2254
Special notes for your reviewer:
Release note: