Skip to content
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

Merged
merged 1 commit into from
Aug 11, 2020

Conversation

humblec
Copy link
Contributor

@humblec humblec commented May 21, 2020

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

The `--csiTimeout` flag of external-resizer is obsoleted with this release. Instead `--timeout` flag has been introduced for the same purpose. The   timeout value  accommodates majority of `ControllerExpandVolume` calls. `timeout` value defaults to 10 seconds. From now on, the deployment  templates or  artifacts has to make use of `--timeout` flag instead of obsoleted `--csiTimeout`  flag.

Signed-off-by: Humble Chirammal [email protected]

@k8s-ci-robot k8s-ci-robot added do-not-merge/release-note-label-needed Indicates that a PR should not merge because it's missing one of the release note labels. cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. labels May 21, 2020
@k8s-ci-robot k8s-ci-robot requested review from gnufied and msau42 May 21, 2020 17:54
@k8s-ci-robot k8s-ci-robot added the size/S Denotes a PR that changes 10-29 lines, ignoring generated files. label May 21, 2020
@Madhu-1
Copy link

Madhu-1 commented May 22, 2020

Fixes #72

cmd/csi-resizer/main.go Outdated Show resolved Hide resolved
@k8s-ci-robot k8s-ci-robot added the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label May 28, 2020
@gnufied
Copy link
Contributor

gnufied commented Aug 5, 2020

@humblec can you update this PR and rebase it?

@k8s-ci-robot k8s-ci-robot removed the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Aug 6, 2020
@humblec
Copy link
Contributor Author

humblec commented Aug 6, 2020

@humblec can you update this PR and rebase it?

Sure. rebased @gnufied . PTAL.

@@ -99,7 +102,7 @@ func main() {

csiResizer, err := resizer.NewResizer(
*csiAddress,
*csiTimeout,
*timeout,
Copy link
Contributor

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?

Copy link
Contributor

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.

Copy link
Contributor

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

Copy link
Collaborator

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.

Copy link
Contributor Author

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?

Copy link
Contributor

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@gnufied @msau42 ok.. are we in agreement to completely remove csiTimeout ?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yep.

Copy link
Contributor Author

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.

Copy link
Contributor

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.

@gnufied
Copy link
Contributor

gnufied commented Aug 7, 2020

/lgtm

@k8s-ci-robot k8s-ci-robot added the lgtm "Looks good to me", indicates that a PR is ready to be merged. label Aug 7, 2020
@gnufied
Copy link
Contributor

gnufied commented Aug 7, 2020

@humblec can you add a release note plz?

@humblec
Copy link
Contributor Author

humblec commented Aug 7, 2020

@gnufied does this looks good as release note for this?


The `--csiTimeout` flag of external-resizer is obsoleted with this release. Instead `--timeout` flag has been introduced for the same purpose. The   timeout value  accommodates majority of `ControllerExpandVolume` calls. `timeout` value defaults to 10 seconds. From now on, the deployment  templates or  artifacts has to make use of `--timeout` flag instead of obsoleted `--csiTimeout`  flag.

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.")
Copy link
Collaborator

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)

Copy link
Contributor Author

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".

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ok.. I changed to 10s default @msau42 @gnufied

Copy link
Contributor

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?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sure @gnufied , so once @msau42 ack on 80s , I will change the default value to the same 👍

Copy link
Contributor Author

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.

Copy link
Contributor

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.

Copy link
Contributor Author

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]>
@k8s-ci-robot k8s-ci-robot added release-note Denotes a PR that will be considered when it comes time to generate release notes. and removed lgtm "Looks good to me", indicates that a PR is ready to be merged. do-not-merge/release-note-label-needed Indicates that a PR should not merge because it's missing one of the release note labels. labels Aug 7, 2020
@gnufied
Copy link
Contributor

gnufied commented Aug 10, 2020

/lgtm

@k8s-ci-robot k8s-ci-robot added the lgtm "Looks good to me", indicates that a PR is ready to be merged. label Aug 10, 2020
@gnufied
Copy link
Contributor

gnufied commented Aug 10, 2020

/approve

@k8s-ci-robot
Copy link
Contributor

[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 /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@k8s-ci-robot k8s-ci-robot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Aug 10, 2020
@@ -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.")
Copy link
Collaborator

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?

Copy link
Contributor

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?

Copy link
Contributor

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.

@humblec
Copy link
Contributor Author

humblec commented Aug 11, 2020

/test pull-kubernetes-csi-external-resizer-1-16-on-kubernetes-1-16

@k8s-ci-robot k8s-ci-robot merged commit ae8826a into kubernetes-csi:master Aug 11, 2020
joshimoo added a commit to joshimoo/longhorn-manager that referenced this pull request Mar 15, 2021
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]>
joshimoo added a commit to longhorn/longhorn-manager that referenced this pull request Mar 15, 2021
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]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
approved Indicates a PR has been approved by an approver from all required OWNERS files. cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. lgtm "Looks good to me", indicates that a PR is ready to be merged. release-note Denotes a PR that will be considered when it comes time to generate release notes. size/S Denotes a PR that changes 10-29 lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants