Retain volumesnapshot-being-created annotation until readyToUse=true #1283
Conversation
k8s-ci-robot
added
release-note
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: pwschuurman The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
k8s-ci-robot
added
the
size/S
|
/assign @sunnylovestiramisu |
|
/lgtm Thanks! |
k8s-ci-robot
added
the
lgtm
pwschuurman
force-pushed
the
retain-snapshot-creating-annotation
branch
from
04ad286 to
ad35797
Compare
k8s-ci-robot
removed
the
lgtm
|
New changes are detected. LGTM label has been removed. |
| content, err = ctrl.removeAnnVolumeSnapshotBeingCreated(content) | ||
| if err != nil { | ||
| return content, fmt.Errorf("failed to remove VolumeSnapshotBeingCreated annotation on the content %s: %q", content.Name, err) | ||
| if contentIsReady(content) { |
There was a problem hiding this comment.
As described in the comments, the annotation is only needed before the snapshot is cut on the storage system. After the snapshot is cut, a snapshot id will be returned and can be used to identify the snapshot on the storage system (if user chooses to delete the snapshot).
I don't see why we have to wait until the snapshot is post processed and ready to use set to true.
|
The Kubernetes project currently lacks enough contributors to adequately respond to all PRs. This bot triages PRs according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale |
k8s-ci-robot
added
the
lifecycle/stale
What type of PR is this?
/kind bug
What this PR does / why we need it:
In
createSnapshotWrapper(), thesnapshot.storage.kubernetes.io/volumesnapshot-being-createdannotation is removed even if the snapshot is not marked asreadyToUsetrue. This is inconsistent with the same logic insyncContent()where we only remove the annotation if the snapshot content is ready:external-snapshotter/pkg/sidecar-controller/snapshot_controller.go
Line 102 in 59d7297
Which issue(s) this PR fixes:
This change may reduce symptoms seen in #1282. However this does not fix the root cause of immedate vs. scheduled exponential backoff requeuing.
Special notes for your reviewer:
Does this PR introduce a user-facing change?: