Why external-snapshotter does not support retry indefinitely until a VolumeSnapshotContent is created?

[gangkui2008]

I wonder why external-snapshotter hard coded the retry count and interval, instead of retrying indefinitely (e.g. exponential backoff) and allow customization like https://github.com/kubernetes-csi/external-provisioner?

From kubernetes-csi/external-snapshotter/pkg/common-controller/snapshot_controller_base.go:

// Number of retries when we create a VolumeSnapshotContent object
const createSnapshotContentRetryCount = 5

// Interval between retries when we create a VolumeSnapshotContent object
const createSnapshotContentInterval = 10 * time.Second

From https://github.com/kubernetes-csi/external-provisioner:

• --retry-interval-start <duration>: Initial retry interval of failed provisioning or deletion. It doubles with each failure, up to --retry-interval-max and then it stops increasing. Default value is 1 second. See CSI error and timeout handling for details.

• --retry-interval-max <duration>: Maximum retry interval of failed provisioning or deletion. Default value is 5 minutes. See CSI error and timeout handling for details.

Thanks!

[xing-yang]

This is because the existing re-queue logic is broken. I have a PR out to fix it. #230

Once that PR is merged, I'll take a look of this.

[xing-yang]

/assign @xing-yang

[gangkui2008]

Okay, thanks very much. I'm looking forward to this feature.

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[xing-yang]

This is fixed by #230