e2e: wait for the provisioner to clean up PV resources #416
Conversation
If we're unlucky, the local-path-provisioner can be killed before it has a chance to clean up orphened PVs. These may then hang around while subsequent tests run. Depending on the lexical sort order of those PVs, the `typeCheckCmd` in `runTest` may select a moribund PV, causing the test to randomly fail.
|
The flaky failure condition seems related the cleanup order of the storageclass. |
|
It's just passing the output of kustomize into kubectl delete. Every kustomize call is (re)installing the storageclass helper. This PR explicitly tags the storageclass stuff so that kubectl delete has a label to only ditch the pod & pvc before it waits on the cleanup completing. |
|
@derekbit is there more required to progress this? |
|
This PR is stale because it has been open 45 days with no activity. Remove stale label or comment or this will be closed in 10 days. |
|
@derekbit I cannot merge this - can you do the honours please? |
Sure. I'm reviewing it. No worries. Will merger it if there is no concern. Thanks you. |
|
@jan-g Could you resolve the conflicts? Thank you. |
2 participants
If we're unlucky, the local-path-provisioner can be killed before it has a chance to clean up orphened PVs. These may then hang around while subsequent tests run. Depending on the lexical sort order of those PVs, the
typeCheckCmdinrunTestmay select a moribund PV, causing the test to randomly fail.