Change:
--terminated-pod-gc-threshold=12500: Number of terminated pods that can exist before the terminated pod garbage collector starts deleting terminated pods. If <= 0, the terminated pod garbage collector is disabled. ``` <del> ###### Auto generated by spf13/cobra on 26-May-2016 </del> <ins> ###### Auto generated by spf13/cobra on 27-May-2016 </ins> <!-- BEGIN MUNGE: GENERATED_ANALYTICS -->

Discussion:
Immediately after this test was reenabled in we got huge numbers of parallel flakes in . This might be a coincidence. I'll make a PR to move it to flaky. If things haven't improved after it's moved then I'll revert, else I'll assign this issue to !
Do you have any logs? references , but that has nothing to do with NFS nor PersistentVolumes.
. It's pretty clear this test caused the flakes we were seeing.
do you have any logs?
It hasn't flaked since your fix went in, but we should keep the issue open until it's moved out of the flaky suite.
The fix Joe Finney developed was merged on 5/30. The signature for the problem in the log file referenced here is: 6 18:56:07.895: Expected PersistentVolume to be bound, but got nil ClaimRef: kind:"" apiVersion:""` It looks like from this dashboard the last instance of this error log signature for the test PersistentVolumes NFS test to the flaky suite. was on 5/30 right around the time the code was merged. I found the off the dashboard at https://k8s- Since then the error has not occurred with that signature since I am tempted to close this bug, but keep the the test suite as marked "Flaky". The merge bot should start flagging the new bugs for this test going forward.
If it's no longer flaky we should move it out of the flaky suite. While it's in the flaky suite it won't block merges if it breaks and mergebot won't open bugs for it. I'm worried that if we just close this issue it'll sit in the flaky suite and break and noone will notice for a long time.
This bug has not been reproduced for past 2 months, can we close it?
It looks like the test is still in the flaky suite, although with a different name. Once it's moved out of there then this can be closed.
[FLAKE-PING] This flaky-test issue would love to have more attention...
[FLAKE-PING] This flaky-test issue would love to have more attention...
Not reproduced for three months, closing.

Consider reducing the PVClaimBinderSyncPeriod from 10 minutes down to something more reasonable, so that volumes don't sit around unbound for half an hour if it fails twice. This would reduce the impact of issues like until the binder/recycler/provosioner consolidation/refactor is complete. CC
+100
do you remember what was the reason for 10 minutes?
I checked provisioner and recycler, lowering the sync period should not harm them. Still, it will impact deleter a bit. Now we try to delete a volume three times every sync-period (10 minutes), mostly because if user deletes a pod that uses a volume and deletes also the PVC bound to it, the volume is still attached to the node for some time and all deletion attempts fail. I've seen AWS detach taking around 5 minutes in some cases. So, if we lower the timer, we should also increase the number of retries. Or have a different retry timer for deletion.