PVC e2e tests are being run on e2e-metal CI clusters even though no k8s storage has been setup. example: https://openshift-gce-devel.appspot.com/build/origin-ci-test/pr-logs/pull/openshift_installer/1621/pull-ci-openshift-installer-master-e2e-metal/4/ ``` [sig-storage] PVC Protection Verify "immediate" deletion of a PVC that is not in active use by a pod [Suite:openshift/conformance/parallel] [Suite:k8s] [sig-storage] PVC Protection Verify that PVC in active use by a pod is not removed immediately [Suite:openshift/conformance/parallel] [Suite:k8s] [sig-storage] PVC Protection Verify that scheduling of a pod that uses PVC that is being deleted fails and the pod becomes Unschedulable [Suite:openshift/conformance/parallel] [Suite:k8s] [sig-storage] PersistentVolumes NFS with Single PV - PVC pairs create a PVC and non-pre-bound PV: test write access [Suite:openshift/conformance/parallel] [Suite:k8s] ``` Expected: storage tests that require PV etc must be skipped when storage is not configured.
I have opened a PR to skip the tests if default SC can not be found - https://github.com/kubernetes/kubernetes/pull/76625 But NFS failure is unrelated to that test fwiw and I am investigating that separately.
These probably depend on default storage class too: [sig-apps] StatefulSet [k8s.io] Basic StatefulSet functionality [StatefulSetBasic] should adopt matching orphans and release non-matching pods [Suite:openshift/conformance/parallel] [Suite:k8s] [sig-apps] StatefulSet [k8s.io] Basic StatefulSet functionality [StatefulSetBasic] should not deadlock when a pod's predecessor fails [Suite:openshift/conformance/parallel] [Suite:k8s] [sig-apps] StatefulSet [k8s.io] Basic StatefulSet functionality [StatefulSetBasic] should perform rolling updates and roll backs of template modifications with PVCs [Suite:openshift/conformance/parallel] [Suite:k8s] [sig-apps] StatefulSet [k8s.io] Basic StatefulSet functionality [StatefulSetBasic] should provide basic identity [Suite:openshift/conformance/parallel] [Suite:k8s]
*** Bug 1700120 has been marked as a duplicate of this bug. ***
*** Bug 1700098 has been marked as a duplicate of this bug. ***
This is blocking installer team's UPI metal and vsphere CI efforts. therefore I hope it is okay to bump to high for 4.1.0
Why will this block vsphere CI efforts? vsphere environment should have a default storageclass configured by default fwiw.
(In reply to Hemant Kumar from comment #6) > Why will this block vsphere CI efforts? vsphere environment should have a > default storageclass configured by default fwiw. This doesn't affect vSphere - the same tests are failing, but for a different reason - tracked in https://bugzilla.redhat.com/show_bug.cgi?id=1699820
Looks like https://github.com/kubernetes/kubernetes/pull/76625 was approved. I will open a backport request.
https://github.com/openshift/origin/pull/22626
I don't think this bug fix needs QE verification. I am going to close this as fixed.