: [sig-auth][Feature:OpenShiftAuthorization][Serial] authorization TestAuthorizationResourceAccessReview should succeed [apigroup:authorization.openshift.io] [Suite:openshift/conformance/serial] expand_more	18s
: [Serial] [sig-auth][Feature:OAuthServer] [RequestHeaders] [IdP] test RequestHeaders IdP [apigroup:config.openshift.io][apigroup:user.openshift.io] [Suite:openshift/conformance/serial] expand_more	2s
: [sig-api-machinery][Feature:APIServer][Late] API LBs follow /readyz of kube-apiserver and stop sending requests before server shutdowns for external clients [Suite:openshift/conformance/parallel] expand_more	35s
: Run multi-stage test e2e-aws-ovn-conformance-serial - e2e-aws-ovn-conformance-serial-conformance-tests container test expand_more	1h40m53s
: Run multi-stage test test phase expand_more

: [Serial] [sig-auth][Feature:OAuthServer] [RequestHeaders] [IdP] test RequestHeaders IdP [apigroup:config.openshift.io][apigroup:user.openshift.io] [Suite:openshift/conformance/serial]
{  fail [github.com/openshift/origin/test/extended/oauth/requestheaders.go:548]: Unexpected error:
    <*errors.StatusError | 0xc007419360>: 
    clusteroperators.config.openshift.io "authentication" not found
    {
        ErrStatus: 
            code: 404
            details:
              group: config.openshift.io
              kind: clusteroperators
              name: authentication
            message: clusteroperators.config.openshift.io "authentication" not found
            metadata: {}
            reason: NotFound
            status: Failure,
    }
occurred}

: [bz-kube-storage-version-migrator] clusteroperator/kube-storage-version-migrator should not change condition/Available expand_less	1h59m39s
{  2 unexpected clusteroperator state transitions during e2e test run.  These did not match any known exceptions, so they cause this test-case to fail:

Mar 08 18:23:14.202 E clusteroperator/kube-storage-version-migrator condition/Available reason/KubeStorageVersionMigrator_Deploying status/False KubeStorageVersionMigratorAvailable: Waiting for Deployment
Mar 08 18:23:14.202 - 16s   E clusteroperator/kube-storage-version-migrator condition/Available reason/KubeStorageVersionMigrator_Deploying status/False KubeStorageVersionMigratorAvailable: Waiting for Deployment

1 unwelcome but acceptable clusteroperator state transitions during e2e test run.  These should not happen, but because they are tied to exceptions, the fact that they did happen is not sufficient to cause this test-case to fail:

Mar 08 18:23:31.028 W clusteroperator/kube-storage-version-migrator condition/Available reason/AsExpected status/True All is well (exception: Available=True is the happy case)
}

 1. 18:23:10 — [sig-cli] Kubectl taint - should remove all the taints with the same key off a node started (test #2 of 63)          
  2. 18:23:14 — That test passed (took 3.7s)                                                                                         
  3. 18:23:14 — At the exact same second, mass disruption began on ip-10-0-142-7: readiness probe failures across many pods,         
  TaintManagerEviction of the KSVM migrator pod

# Migrator deployment:
    name: migrator
    namespace: openshift-kube-storage-version-migrator
  spec:
    replicas: 1

[sig-network][Feature:EgressIP][apigroup:operator.openshift.io] [external-targets][apigroup:user.openshift.io][apigroup:security.openshift.io] pods should have the assigned EgressIPs and EgressIPs can be updated [Skipped:Network/OpenShiftSDN] [Serial] [Suite:openshift/conformance/serial] expand_less	4m5s
{  fail [github.com/openshift/origin/test/extended/networking/egressip.go:360]: Unexpected error:
    <*errors.errorString | 0xc002c64000>: 
    Daemonset still not ready after 48 tries: ready=1, scheduled=2, desired=2
    {
        s: "Daemonset still not ready after 48 tries: ready=1, scheduled=2, desired=2",
    }
occurred
Ginkgo exit error 1: exit with code 1}

  What happened step by step:

  1. The test created a DaemonSet e2e-test-egressip-2hsmd-packet-sniffer that needed to run on 2 EgressIP-assignable worker nodes:
    - ip-10-0-136-208.ec2.internal — pod 72f2v
    - ip-10-0-137-113.ec2.internal — pod tvtwf
  2. Pod 72f2v (on ip-10-0-136-208): Successfully pulled the image in ~18.8 seconds (19:51:16 → 19:51:35), started the tcpdump container, and became Ready. Image size was ~1.8 GB.
  3. Pod tvtwf (on ip-10-0-137-113): Started pulling the same image at 19:51:16 but the image pull never completed. The container stayed in ContainerCreating state from 19:51:16 until 19:55:49 (when the pod was gracefully deleted after test failure). There is no Pulled, Created container, or Started event for this pod — the image pull simply hung or was extremely slow on this node.
  4. After 48 retry checks (~4 minutes), the JustBeforeEach at egressip.go:360 timed out and failed the test.

Why the image pull stalled on ip-10-0-137-113:

The cluster was experiencing image pull QPS throttling at the time. Other pods in the cluster (e.g., in namespace e2e-job-7003) were hitting ErrImagePull: pull QPS exceeded errors. The large image size (~1.8 GB from registry.ci.openshift.org) combined with container runtime pull QPS limits likely caused the pull on node ip-10-0-137-113 to be throttled or queued behind other pulls, preventing it from completing within the DaemonSet readiness timeout.