-
Task
-
Resolution: Duplicate
-
Undefined
-
None
-
None
-
None
-
False
-
False
-
-
ShiftStack Sprint 215, ShiftStack Sprint 216
We did hit an issue running these fsgroup tests against the cloud-provider-openstack repo as well, a discussion is captured in this PR: https://github.com/kubernetes/clouThis causes the timeouts we're seeing in the snapshot tests, since the driver never created the snapshotd-provider-openstack/pull/1762
Citing the linked issue:
> It seems like it's trying to delete a PVC that's still in use by a Pod, and then fails due to timeout when attempting to delete that PVC.
That is a perfectly legal operation. Both Pods and PVCs are end user objects and we should not trust them too much. The CSI driver should be robust to survive this. Otherwise a bad user can break the whole OCP cluster easily by doing that in a loop and ending up with millions of pods that can't be deleted.
> it also deleted storage class of a PVC before deleting that PVC, which then causes deletion of that PVC to fail (can't access the provisioner secrets anymore).
This is suspicious. It should not happen during a correct test run, let us know if it does, however, we know it happens when cleaning up after a failed test. Don't fail the tests in the first place
.
We run the same tests for AWS EBS and GCE PD. They don't use any secrets in StorageClass / VolumeSnapshotClass though.
https://testgrid.k8s.io/redhat-openshift-ocp-release-4.10-informing#periodic-ci-openshift-release-master-nightly-4.10-e2e-aws-csi
https://testgrid.k8s.io/redhat-openshift-ocp-release-4.10-informing#periodic-ci-openshift-release-master-nightly-4.10-e2e-gcp-csi
- relates to
-
OSASINFRA-2787 ManilaCSI GA readiness & testing
-
- Closed
-