GCE e2e build/test passed for commit bcc1b68.

• Test Results
• Build Log
• Test Artifacts
• Internal Jenkins Results

Is the reaper going to properly handle 404's? It's going to race with the garbage collector to delete all of the pods now, right?

Reaper uses the scaler, which updates the rc.spec.replicas to 0, rc manager will deletes the pods.

kubectl waits until all the pods are gone, then it sends the delete request for the RC. Garbage collector may still have the pods in its local cache and will try to delete them, it ignores the 404. So there is no race.

OK, that sounds good. I guess the next step is to just get rid of the reaper, or to have it check the cluster version before running? We can turn that on in the future though.

LGTM

I guess the next step is to just get rid of the reaper, or to have it check the cluster version before running? We can turn that on in the future though.

Yes. We also need to implement the waitForGCDone DeleteOption before moving kubectl to use GC.

Reviewed 1 of 1 files at r1.
Review status: all files reviewed at latest revision, all discussions resolved.

Comments from Reviewable

@k8s-bot test this [submit-queue is verifying that this PR is safe to merge]

GCE e2e build/test passed for commit bcc1b68.

• Test Results
• Build Log
• Test Artifacts
• Internal Jenkins Results

Automatic merge from submit-queue