Loading
Accept pod watcher errors in prepare-stage pod termination test
What does this MR do?
Relaxes the prepare-stage case of testDeletedPodSystemFailureDuringExecution to accept the pod watcher's "is being deleted" and "is disrupted" errors in addition to NotFound.
Why was this MR needed?
The prepare-stage case assumed that a pod deleted or evicted during prepare never reaches Running, so the only possible failure would be "pods ... not found" from the poll loop. That doesn't hold for graceful termination: the pod can become Running and Ready within the 5 second grace period the test config uses. Prepare then succeeds and the runner returns the pod watcher's error instead. For eviction that's pod ... is disrupted: reason "EvictionByEvictionAPI".
Which error you get depends on how fast the pod starts, so the test flaked. Example failure in the "integration kubernetes exec legacy" job.
Both outcomes are correct runner behaviour, a system failure with an accurate message. The step_ cases of the same test already accept this race, with a comment explaining it. This applies the same assertion to the prepare-stage case.
What's the best way to test this MR?
Run the kubernetes integration jobs. The flaky subtest is testDeletedPodSystemFailureDuringExecution/.../prepare_script/evict_gracefully.