-
Notifications
You must be signed in to change notification settings - Fork 337
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
Fix GetDriverName timeout #239
Fix GetDriverName timeout #239
Conversation
It should be CSI call timeout, not connection timeout.
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: jsafrane 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 |
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.
Perhaps change
connectionTimeout = flag.Duration("connection-timeout", 0, "This option is deprecated.")
into
_ = flag.Duration("connection-timeout", 0, "This option is deprecated.")
to prevent accidentally using it?
Just an idea, we can also merge as-is.
There is warning when the option is used and I'd like to keep it there. external-provisioner/cmd/csi-provisioner/csi-provisioner.go Lines 80 to 82 in f588078
|
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
The warning for the deprecated connection-timeout was only printed when it was set to a non-default value. When set explicitly to zero (admittedly unlikely), no warning was printed. This approach also gets rid of the actual variable and thus catches code which accidentally still uses it (see kubernetes-csi#239).
The warning for the deprecated connection-timeout was only printed when it was set to a non-default value. When set explicitly to zero (admittedly unlikely), no warning was printed. This approach also gets rid of the actual variable and thus catches code which accidentally still uses it (see kubernetes-csi#239).
The warning for the deprecated connection-timeout was only printed when it was set to a non-default value. When set explicitly to zero (admittedly unlikely), no warning was printed. This approach also gets rid of the actual variable and thus catches code which accidentally still uses it (see kubernetes-csi#239).
The warning for the deprecated connection-timeout was only printed when it was set to a non-default value. When set explicitly to zero (admittedly unlikely), no warning was printed. This approach also gets rid of the actual variable and thus catches code which accidentally still uses it (see kubernetes-csi#239).
Several sidecars (for example, external-provisioner) deprecate command line flags. When that happens, the flag must still be treated the same way as before (i.e. optional values for boolean, required values for non-boolean), but trying to use the flag needs to trigger a deprecation warning. An alternative to this code is to let the flag set a variable and then check the variable. But that only catches cases where the variable is set to a non-default value and leaves the variable in the code, which can lead to mistakes (see kubernetes-csi/external-provisioner#239).
The warning for the deprecated connection-timeout was only printed when it was set to a non-default value. When set explicitly to zero (admittedly unlikely), no warning was printed. This approach also gets rid of the actual variable and thus catches code which accidentally still uses it (see kubernetes-csi#239).
The warning for the deprecated connection-timeout was only printed when it was set to a non-default value. When set explicitly to zero (admittedly unlikely), no warning was printed. This approach also gets rid of the actual variable and thus catches code which accidentally still uses it (see kubernetes-csi#239). This depends on a more recent csi-lib-utils. Because the previous vendoring was done with an older dep version, "dep ensure -update" cannot update just that project, so everything gets updated instead.
Prepare v3 release
It should be CSI call timeout, not deprecated connection timeout.
cc @pohly