Poll: how to fix e2e-test-kubevirt-aws hitting the 2h Prow step timeout

Context: while validating PR #2404, ci/prow/5.0-e2e-test-kubevirt-aws failed by hitting Prow's default 2h step timeout (sigs.k8s.io/prow/pkg/entrypoint.DefaultTimeout, no override set in this job's openshift/release config).

Update: the spec that hits CNV-85377/CNV-89684 (checkpoint deletion with maxIncrementalBackups=0) is already scaffolded as a ginkgo.PIt (compile-time pending) in PR #2404 -- it contributes zero runtime, since it never executes. Recent runs confirm this: no occurrence of that freeze pattern, yet the job still hits the 2h ceiling. The real breakdown, from an actual recent run's per-spec durations (test-execution phase only, which is what the 2h ceiling applies to):

• 8 non-kdm CSI/CSI+datamover specs (this job runs TEST_VIRT=true, the full virt suite, not scoped to kdm): ~326-738s each, summing to ~60 min
• "full backup, incremental chain, restart, and max-limit fallback" (does 4 sequential backups in one It): ~24.5 min
• "restore run-state flip..." and "restore a multi-PVC VM..." (PR #2404's two newly-unpended kdm specs, previously PIt, now real): ~10 min and ~24 min respectively

Total: ~1h55m of test-execution alone, already brushing the ~120min ceiling before counting cluster-install time separately -- and PR #2404's two newly-real specs are the straw that pushes some runs over. This is plain additive overrun from legitimate spec runtime, not any single stuck/flaking spec.

Vote by reacting 👍 on the option(s) you'd support (multiple OK if you see them as complementary):

A — Bump the timeout
Add timeout: 3h0m0s to this job's test step in openshift/release. Minimal, fast, no test-code risk. Doesn't address the underlying runtime growth — just buys headroom.

B — Split into two jobs
e2e-test-kubevirt-aws (non-kdm CSI, ~60m) + a new kdm-only job (TEST_VIRT_KDM=true, ~50m+ and growing as more kdm specs get unpended). Both comfortably clear the 2h default with no override needed, and CI feedback arrives in parallel instead of serially. Costs a second job's cluster-bootstrap overhead (~47m) and more openshift/release config to maintain.

C — Eliminate redundant coverage
Audit whether the 9 non-kdm CSI specs are already covered by another virt CI job; if so, drop them from this job. Best long-term fix (real time saved, not just a bigger budget) but needs the audit done first.

D — Fail fast on the known-unfixable flake
~~CNV-89684 hits every AWS kdm run so far with no retry ever recovering it. Reduce flakeAttempts to 1 (or skip immediately) for the affected specs on AWS instead of paying the ~20m wait each time.~~ **Superseded**: the CNV-85377/CNV-89684-affected spec is already ginkgo.PIt (pays zero runtime), and recent runs show the timeout is driven by plain additive real-spec runtime, not this flake recurring. No longer a relevant option here.

My updated read: A as an immediate stopgap while C gets investigated, with B as the follow-up if C shows the CSI specs aren't actually redundant elsewhere — but posting for the team to weigh in rather than deciding unilaterally.

[!Note]
Responses generated with Claude

Start with the ci/prow/5.0-e2e-test-kubevirt-aws job in the openshift/release configuration and review the reported per-spec durations. Then audit whether the nine non-kdm CSI specs run in another virt CI job. Done means the team has selected and implemented a timeout, split-job, or coverage-reduction approach that keeps the test-execution phase within its limit.