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
Transport.RoundTrip should return a non-nil for failure to obtain a response. #92217
Transport.RoundTrip should return a non-nil for failure to obtain a response. #92217
Conversation
/assign @sttts |
b018046
to
212f3cd
Compare
/retest |
212f3cd
to
32a4ed6
Compare
32a4ed6
to
f5978bc
Compare
/lgtm |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: p0lyn0mial, sttts 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 |
/retest Review the full test history for this PR. Silence the bot with an |
1 similar comment
/retest Review the full test history for this PR. Silence the bot with an |
@@ -261,7 +261,7 @@ func TestProxyHandler(t *testing.T) { | |||
}, | |||
}, | |||
}, | |||
expectedStatusCode: http.StatusServiceUnavailable, |
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 would still expect this to surface a 503 error to the caller
/hold
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.
This particular test case fails due to incorrect APIService
configuration, that leads to error trying to reach service: x509: certificate is valid for test-service.test-ns.svc, not ..svc
. It sounds like a configuration error because at this point we don't know if the server we are trying to reach is available.
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.
from a consistency perspective, if the periodic healthcheck for the APIService encountered this cert error, it would flip the APIService to unavailable, and this code would return a 503:
kubernetes/staging/src/k8s.io/kube-aggregator/pkg/apiserver/handler_proxy.go
Lines 125 to 128 in e2d8f6c
if !handlingInfo.serviceAvailable { | |
proxyError(w, req, "service unavailable", http.StatusServiceUnavailable) | |
return | |
} |
It's unclear to me why the same error encountered by the proxy synchronously would surface a different error code to the requesting user
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.
to preserve the old behaviour we could change the default responder https://github.com/kubernetes/kubernetes/blob/master/staging/src/k8s.io/kube-aggregator/pkg/apiserver/handler_proxy.go#L240 to return http.StatusServiceUnavailable
, are you okay with that?
it seems that it's only used by the proxy - https://github.com/kubernetes/kubernetes/blob/master/staging/src/k8s.io/kube-aggregator/pkg/apiserver/handler_proxy.go#L178
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.
done.
Now the default responder will return StatusServiceUnavailable
, this aligns with the old behavior of the Transport
. It looks like it safe to do so because the default responder wasn't wired before (https://github.com/kubernetes/kubernetes/pull/92217/files#diff-16a26bb0d342318c6eb3d03e6c5756e9R239)
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.
that seems better to me, thanks. will let @sttts ack before merge
/hold cancel
f5978bc
to
c0593b6
Compare
/test pull-kubernetes-integration |
// if an optional error interceptor/responder was provided wire it | ||
// the custom responder might be used for providing a unified error reporting | ||
// or supporting retry mechanisms by not sending non-fatal errors to the clients | ||
proxy.ErrorHandler = h.Responder.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.
/lgtm |
What type of PR is this?
/kind bug
What this PR does / why we need it: In general
RoundTrip
should not attempt to interpret the response. In particular,RoundTrip
must returnerr
== nil if it obtained a response, regardless of the response'sHTTP
status code. Anon-nil
err should be reserved for failure to obtain a response.This allows higher-level layers to interpret the
err
and construct the final response to the client.Which issue(s) this PR fixes:
Fixes #
Special notes for your reviewer:
Does this PR introduce a user-facing change?:
Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.: