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
Allow passing request-timeout from NewRequest all the way down #51042
Conversation
@@ -130,6 +130,7 @@ func NewRequest(client HTTPClient, verb string, baseURL *url.URL, versionedAPIPa | |||
serializers: serializers, | |||
backoffMgr: backoff, | |||
throttle: throttle, | |||
timeout: timeout, |
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.
Can you describe what you think this sets? It actually sets a query parameter on our request for the apiserver to consume, not a timeout on the client side. I doubt that's what most callers would expect.
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's exactly my intention with this change. The downstream problem (https://bugzilla.redhat.com/show_bug.cgi?id=1433244) was that --request-timeout
wasn't passed to apiserver, which although I've allowed this functionality to be long-running request, is being cut off by the apiserver.
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.
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.
@deads2k the client-side timeout added by #33958 did not handles cases where the user requested a longer timeout, but the apiserver ended the request first. --request-timeout worked under the assumption that the client would be the one always terminating the connection
@juanvallejo more specifically. You think using the same value for both is a good idea?
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 user POV - I think the answer is yes. I'm not 100% sure about eventual downsides, though.
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'm fine with having both match if the CLI behavior matches expectations. @juanvallejo and @fabianofranz probably have more opinion there.
Is this set non-zero somewhere? The code you updated all seems to set zero
/unassign @resouer @smarterclayton |
@fabianofranz do you have any objections here, if not I'd like to rebase it and push it forward? |
@soltysh works for me. |
} | ||
return NewRequest(c.Client, verb, c.base, c.versionedAPIPath, c.contentConfig, c.serializers, backoff, c.Throttle) | ||
return NewRequest(c.Client, verb, c.base, c.versionedAPIPath, c.contentConfig, c.serializers, backoff, c.Throttle, 0) |
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 line is different in your patch in origin. Which is it supposed to be?
f881544
to
ce1c7bc
Compare
@juanvallejo @deads2k I've updated the PR ptal |
/lgtm |
/retest Review the full test history for this PR. Silence the bot with an |
7 similar comments
/retest Review the full test history for this PR. Silence the bot with an |
/retest Review the full test history for this PR. Silence the bot with an |
/retest Review the full test history for this PR. Silence the bot with an |
/retest Review the full test history for this PR. Silence the bot with an |
/retest Review the full test history for this PR. Silence the bot with an |
/retest Review the full test history for this PR. Silence the bot with an |
/retest Review the full test history for this PR. Silence the bot with an |
/hold |
ce1c7bc
to
7da1002
Compare
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: deads2k, soltysh The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these OWNERS Files:
You can indicate your approval by writing |
/hold cancel |
/retest Review the full test history for this PR. Silence the bot with an |
/test all [submit-queue is verifying that this PR is safe to merge] |
@soltysh: The following tests failed, say
Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here. |
Automatic merge from submit-queue (batch tested with PRs 59276, 51042, 58973, 59377, 59472). If you want to cherry-pick this change to another branch, please follow the instructions here. |
What this PR does / why we need it:
Currently if you pass
--request-timeout
it's not passed all the way down to the actual request object. There's a separate field on theRequest
object that allows setting that timeout, but it's not taken from that flag.@smarterclayton @deads2k ptal, this is coming from openshift/origin#13701