Add --poll-snapshot-period for periodic readiness requeue check when creating a VolumeSnapshotContent #1284
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What type of PR is this?
/kind feature
What this PR does / why we need it:
Today, the csi-snapshotter runs with a reconciler pattern when processing VolumeSnapshotContent resources. This follows the familiar
requeue, err
pattern that is followed by other controller frameworks, like controller-runtime.requeue
field is useful, as the reconciler can periodically attempt to check the status of a snapshot.The problem with the current requeue implementation is that it relies on the same exponential backoff rate limiter queue as the error handling scenario. This is a problem, as it can lead to non-deterministic ready times, and can lead to significantly higher effective snapshot ready latencies for snapshots that take longer to process (eg: larger snapshots).
To fix this, the requeue logic should use a constant retry period, to allow for more reliable snapshot reconciliation. This PR adds a new command line argument
--poll-snapshot-period
to the csi-snapshotter, with a default of10 seconds
.Which issue(s) this PR fixes:
Fixes #1282
Special notes for your reviewer:
Does this PR introduce a user-facing change?: