-
Notifications
You must be signed in to change notification settings - Fork 807
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
Change modifyVolumeRequestHandlerTimeout to a configurable option #1915
Conversation
Welcome @andrewcharlton! |
Hi @andrewcharlton. Thanks for your PR. I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. 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. |
/ok-to-test |
Hello folks, it's very important to make sure that both Timeouts both in |
Code Coverage Diff
|
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
Hello folks,
One important thing to note about this change:it's very important to make sure that both
resizer
andmodifier
timeout args are higher than the specifiedmodify-volume-request-handler-timeout
, otherwise users might have contex timeout errors on requests from those to gRPC endpoints in csi-controller.Timeouts both in
resizer
andmodifier
are by default 10s.
Maybe worth adding a comment about this to the code, or to the docs?
Thanks, I've added a comment in both the docs, and the descriptor for the flag. I added an additional testcase that I'd missed for the flag as well. Hope that's ok! |
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.
Thanks @andrewcharlton
/lgtm
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
/label tide/merge-method-squash
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.
Thanks for this
/approve |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: torredil 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 |
Is this a bug fix or adding new feature?
New feature
What is this PR about? / Why do we need it?
This PR changes the
modifyVolumeRequestHandlerTimeout
, which was previously hardcoded to 2 seconds, into an option that the user can specify. If it is not specified, this should be a complete no-op and default to 2 seconds as before.The
modifyVolumeRequestHandlerTimeout
determines how long the controller will wait for additional volume modification calls before executing them and modifying the volume. When changing both the size and IOPs/Throughput of a volume simultaneously there are two calls made and they need to be coalesced together within this window for a single call to AWS to be made. We have seen cases where the 2 seconds is not long enough for this to happen, and only a single one of those changes is made so we would like to extend the window for our use case, where it is more important that the change be atomic than it's latency.Issue discussing this: #1911
What testing is done?
Added unit test for the new option. Updated coalesce tests to ensure they use the value from the option.
We have a fork with a larger timeout window running in our environment successfully.