From 7fac9cdaf87a7d859771e9147a4797d582d6b8df Mon Sep 17 00:00:00 2001 From: Sameer Shaikh Date: Thu, 29 Jun 2023 21:17:27 +0530 Subject: [PATCH] external-snapshotter constantly retrying CreateSnapshot calls on error w/o backoff --- pkg/sidecar-controller/snapshot_controller_base.go | 11 +++-------- 1 file changed, 3 insertions(+), 8 deletions(-) diff --git a/pkg/sidecar-controller/snapshot_controller_base.go b/pkg/sidecar-controller/snapshot_controller_base.go index bd4e695b..427d85de 100644 --- a/pkg/sidecar-controller/snapshot_controller_base.go +++ b/pkg/sidecar-controller/snapshot_controller_base.go @@ -115,14 +115,9 @@ func NewCSISnapshotSideCarController( cache.ResourceEventHandlerFuncs{ AddFunc: func(obj interface{}) { ctrl.enqueueContentWork(obj) }, UpdateFunc: func(oldObj, newObj interface{}) { - // If the CSI driver fails to create a snapshot and returns a failure (indicated by content.Status.Error), the - // CSI Snapshotter sidecar will remove the "AnnVolumeSnapshotBeingCreated" annotation from the - // VolumeSnapshotContent. - // This will trigger a VolumeSnapshotContent update and it will cause the obj to be re-queued immediately - // and CSI CreateSnapshot will be called again without exponential backoff. - // Considering the object is modified more than once during the workflow we are not relying on the annoations of oldobj and newobj. - // We will just check if newobj status has error and avoid re-queue. - // So we are skipping the re-queue here to avoid CreateSnapshot being called without exponential backoff. + // Considering the object is modified more than once during the workflow we are not relying on the + // "AnnVolumeSnapshotBeingCreated" annotation. Instead we will just check if newobj status has error + // and avoid the immediate re-queue. This allows the retry to happen with exponential backoff. newSnapContent := newObj.(*crdv1.VolumeSnapshotContent) if newSnapContent.Status != nil && newSnapContent.Status.Error != nil { return