Change:
AccessModes: []v1.PersistentVolumeAccessMode{ v1.ReadWriteOnce, v1.ReadOnlyMany, <del> v1.ReadWriteMany, </del> }, Resources: v1.ResourceRequirements{ Requests: v1.ResourceList{

Discussion:
<!-- Please only use this template for submitting reports about flaky tests or jobs (pass or fail with no underlying change in code) in Kubernetes CI --Which jobs are flaking: ci-kubernetes-e2e-ubuntu-gce-containerd Which test(s) are flaking: [sig-api-machinery] ResourceQuota should create a ResourceQuota and capture the life of a persistent volume claim with a storage class. [sig-storage] Testgrid link: Reason for failure: Anything else we need to know: links to appreciated Few other instances:
/sig api-machinery
Thank you for reporting this. Worth noting I think, that the test has failed with timeout across a multiple jobs (the triage link you provided lists them there) Also, there are additional failure reasons present on the triage page when run from e2e-kops-* jobs Again more details at the bottom of the triage page for . and /cc
/cc
looks like this test still periodically times out, would be great if someone could take a look
can you look and find an owner?
Ensuring resource quota status captures persistent volume claim creation Nov 8 00:00:58.461: INFO: resource persistentvolumeclaims, expected 1, actual 0 Nov 8 00:01:00.449: INFO: resource persistentvolumeclaims, expected 1, actual 0 Nov 8 00:01:03.123: INFO: resource persistentvolumeclaims, expected 1, actual 0 Nov 8 00:01:04.545: INFO: resource persistentvolumeclaims, expected 1, actual 0 Nov 8 00:01:06.529: INFO: resource persistentvolumeclaims, expected 1, actual 0 Nov 8 00:01:08.499: INFO: resource persistentvolumeclaims, expected 1, actual 0 Nov 8 00:01:10.471: INFO: resource persistentvolumeclaims, expected 1, actual 0 Nov 8 00:01:12.624: INFO: resource requests.storage, expected 1Gi, actual 0 Nov 8 00:01:14.612: INFO: resource persistentvolumeclaims, expected 1, actual 0 Nov 8 00:01:16.494: INFO: resource persistentvolumeclaims, expected 1,

actual 0 Nov 8 00:01:18.661: INFO: resource persistentvolumeclaims, expected 1, actual 0 Nov 8 00:01:20.488: INFO: resource persistentvolumeclaims, expected 1, actual 0 Nov 8 00:01:22.432: INFO: resource persistentvolumeclaims, expected 1, actual 0 Nov 8 00:01:24.963: INFO: resource persistentvolumeclaims, expected 1, actual 0 Nov 8 00:01:26.634: INFO: resource persistentvolumeclaims, expected 1, actual 0 Nov 8 00:01:26.959: INFO: resource persistentvolumeclaims, expected 1, actual 0 Nov 8 00:01:26.959: FAIL: Unexpected error: <errors.errorString | 0xc0001fa1f0: { s: "timed out waiting for the condition", } timed out waiting for the condition occurred Full Stack Trace () +0x8e5 (0xc002c66300) +0x345 (0xc002c66300) +0x2b testing.tRunner(0xc002c66300, 0x4dca5d0) +0xef created by testing.(T).Run +0x386 [AfterEach] [sig-api-machinery] ResourceQuota 1mSTEP0m: Collecting events from namespace "resourcequota-383". 1mSTEP0m: Found 1 events. Nov 8 00:01:27.139: INFO: At 2020-11-08 00:00:57 +0000 UTC - event for test-claim: {persistentvolume-controller } ProvisioningFailed: Failed to provision volume with StorageClass "standard": invalid AccessModes [ReadWriteOnce ReadOnlyMany ReadWriteMany]: only AccessModes [ReadWriteOnce ReadOnlyMany] are supported
As the errors pointed out, the PVC failed to be provisioned due to invalid access mode specified.

Nov 8 00:01:27.139: INFO: At 2020-11-08 00:00:57 +0000 UTC - event for test-claim: {persistentvolume-controller } ProvisioningFailed: Failed to provision volume with StorageClass "standard": invalid AccessModes [ReadWriteOnce ReadOnlyMany ReadWriteMany]: only AccessModes [ReadWriteOnce ReadOnlyMany] are supported