-
Notifications
You must be signed in to change notification settings - Fork 133
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
Replace csiTimeout
to timeout
param for resizer
#82
Conversation
Fixes #72 |
@humblec can you update this PR and rebase it? |
@@ -99,7 +102,7 @@ func main() { | |||
|
|||
csiResizer, err := resizer.NewResizer( | |||
*csiAddress, | |||
*csiTimeout, | |||
*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.
this means that if someone was using deprecated parameter - csiTimeout
, it will simply be ignored. Can you fix it?
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.
Since in this release we are only deprecating the older csiTimeout
parameter (as evident from CLI help flags), but if we remove the flag in the same release we will have problems.
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.
alternately - if we are not going to support csiTimeout
flag anymore, we should remove it alogether. But I am in favour of deprecating the flag for now and removing it later. cc @msau42
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.
If someone sets csiTimeout, can we have it set timeout?
I'm also ok with just removing the flag because we're doing a major release anyway.
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.
Ok.. let me try to explain what I was thinking. Being this is a major release, we could definitely mark csitimeout
param as a "deprecated" one , also we could mention in the release note that if someone set this value , it will be NO-OP and the default timeout value in the external resizer will be used. The advantage with this approach is that, the older templates ( which set csiTimeout
) in some customer/user setup could also work , but its a NO-OP . If they set timeout
while using new templates in parity with this release, it will be effective as well. Isnt it a good idea to address this way? @gnufied @msau42 wdyt?
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 would be problematic. It would seem like we still support csiTimeout
option but in truth we don't. If we are going to not support csiTimeout
option then we should just remove it.
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.
yep.
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.
@gnufied ptal on current version.. completely removed csiTimeout
.
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.
hmm, I think what @msau42 meant was 15s itself is too low of a default (and hence 10s will be even lower) and hence is it worth forcing COs/cluster-admins to specify a value rather than choosing a non-ideal default?
I see @msau42 point but I kinda like the idea of defaults, but I admit 15s is not good default for volume expansion. I wonder if we can increase the default to something like 80s which would work in most cases and if certain drivers have problems they can tune it.
Also this PR will require fixing all our e2e jobs btw.
/lgtm |
@humblec can you add a release note plz? |
@gnufied does this looks good as release note for this?
|
cmd/csi-resizer/main.go
Outdated
csiAddress = flag.String("csi-address", "/run/csi/socket", "Address of the CSI driver socket.") | ||
csiTimeout = flag.Duration("csiTimeout", 15*time.Second, "Timeout for waiting for CSI driver socket.") | ||
csiAddress = flag.String("csi-address", "/run/csi/socket", "Address of the CSI driver socket.") | ||
timeout = flag.Duration("timeout", 15*time.Second, "Timeout for waiting for CSI driver socket.") |
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.
How come 15? All the other sidecars are 10 seconds. Actually, do we want to default a timeout value? I find 10 seconds is quite short for real drivers. xref: kubernetes-csi/external-provisioner#451 (comment)
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.
@msau42 sure we can keep in parity between sidecars ie 10 seconds. I kept it 15 seconds as obsoleted csitimeout
default was "15s".
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.
Also - I kind of dislike, renaming the parameter and making it required in same release. It causes problems for downstream users. So, if we choose to make this parameter mandatory, we should do this in 2.0 IMO.
@msau42 does 80s as a default sound good to you? The reason I picked this is because, from my experience this is "good enough" default for most in-tree plugins for which there is a equivalent CSI driver. If we all agree @humblec can you update the PR to use 80s
as default 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.
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.
Also, I do second to 2.0.0
with this new parameter instead of changing it in the minor release.
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.
we spoke in CSI implementation call today. It was decided that, 10s is a good default because it exposes driver idempotency issues and specific drivers can tune this value.
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 the update @gnufied ! 👍
At present the resizer has CSI call timeout value taken as arg in form of `--csiTimeout` , however all other sidecars have this parameter as `--timeout`. This patch replaces `csiTimeout` to `timeout` value NOTE: This is a breaking change, so we need a new release Signed-off-by: Humble Chirammal <[email protected]>
/lgtm |
/approve |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: gnufied, humblec 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 |
@@ -44,8 +45,9 @@ var ( | |||
resyncPeriod = flag.Duration("resync-period", time.Minute*10, "Resync period for cache") | |||
workers = flag.Int("workers", 10, "Concurrency to process multiple resize requests") | |||
|
|||
csiAddress = flag.String("csi-address", "/run/csi/socket", "Address of the CSI driver socket.") | |||
csiTimeout = flag.Duration("csiTimeout", 15*time.Second, "Timeout for waiting for CSI driver socket.") | |||
csiAddress = flag.String("csi-address", "/run/csi/socket", "Address of the CSI driver socket.") |
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.
Since we're going to ignore this csiAddress flag, should we use the deprecatedflag library?
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.
wait, why is csiAddress
being ignored?
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.
sorry this got merged before this has chance to get addressed. but we can do a follow up.
/test pull-kubernetes-csi-external-resizer-1-16-on-kubernetes-1-16 |
We are using a really old csi resizer image, that doesn't yet support the new `timeout` param, instead it relies on an old `csiTimeout` param. Decided against updating the csi images and instead will do a full update of all the csi images for 1.2. See kubernetes-csi/external-resizer#82 Longhorn longhorn#2347 Signed-off-by: Joshua Moody <[email protected]>
We are using a really old csi resizer image, that doesn't yet support the new `timeout` param, instead it relies on an old `csiTimeout` param. Decided against updating the csi images and instead will do a full update of all the csi images for 1.2. See kubernetes-csi/external-resizer#82 Longhorn #2347 Signed-off-by: Joshua Moody <[email protected]>
At present the resizer has CSI call timeout value
taken as arg in form of
--csiTimeout
, however allother sidecars have this parameter as
--timeout
.This patch replaces
csiTimeout
totimeout
valueNOTE: This is a breaking change, so we need a new release
Signed-off-by: Humble Chirammal [email protected]