Do not report error when deleting an attached volume #31978
Conversation
jsafrane
added
sig/storage
|
cc @kubernetes/sig-storage |
k8s-github-robot
added
the
size/L
|
Do we want this in 1.4 (maybe 1.4.1) ? On Fri, Sep 2, 2016 at 7:52 AM, Kubernetes Submit Queue <
|
jsafrane
force-pushed
the
detach-before-delete
branch
from
9a18e50
to
3197036
Compare
| glog.V(4).Infof("deleteVolumeOperation [%s]: failed to mark volume as failed: %v", volume.Name, err) | ||
| // Save failed, retry on the next deletion attempt | ||
| return | ||
| if vol.IsTryAgain(err) { |
There was a problem hiding this comment.
How frequent is the retry? Is it worth doing exponential backoff?
There was a problem hiding this comment.
Every controller sync, which is 15 seconds by default. And it does not start new delete until an old one (on the same PV) returns.
jsafrane
force-pushed
the
detach-before-delete
branch
2 times, most recently
from
9023ec9
to
d20131d
Compare
k8s-github-robot
added
the
needs-rebase
jsafrane
force-pushed
the
detach-before-delete
branch
from
d20131d
to
a24e6a9
Compare
|
rebased |
k8s-github-robot
added
size/M
k8s-github-robot
added
size/L
1 similar comment
|
GCE e2e build/test passed for commit 9903b38. |
|
I am shadowing this review. lgtm! |
|
LGTM |
saad-ali
added
the
lgtm
|
@k8s-bot test this [submit-queue is verifying that this PR is safe to merge] |
|
Jenkins GKE smoke e2e failed for commit 9903b38. Full PR test history. The magic incantation to run this job again is |
|
Automatic merge from submit-queue |
Automatic merge from submit-queue Do not report error when deleting an attached volume Persistent volume controller should not send warning events to a PV and mark the PV as failed when the volume is still attached. This happens when a user quickly deletes a pod and associated PVC - PV is slowly detaching, while the PVC is already deleted and the PV enters Failed phase. `Deleter.Deleter` can now return `tryAgainError`, which is sent as INFO to the PV to let the user know we did not forget to delete the PV, however the PV stays in Released state. The controller tries again in the next sync (15 seconds by default). Fixes kubernetes#31511
Persistent volume controller should not send warning events to a PV and mark the PV as failed when the volume is still attached.
This happens when a user quickly deletes a pod and associated PVC - PV is slowly detaching, while the PVC is already deleted and the PV enters Failed phase.
Deleter.Deletercan now returntryAgainError, which is sent as INFO to the PV to let the user know we did not forget to delete the PV, however the PV stays in Released state. The controller tries again in the next sync (15 seconds by default).Fixes #31511
This change is