2 deployer pods are present for a brief moment

[tnozicka]

This is probably because we don't wait for them to be deleted and allow deploying newer RC just because the old one is marked cancelled but this doesn't mean the deployer pod has been deleted yet as that is handled asynchronously by deployer controller.

@smarterclayton this is the issue you pinged me about
cc: @mfojtik

Seen in https://ci.openshift.redhat.com/jenkins/job/zz_origin_gce_image/502/testReport/junit/(root)/Extended/_Feature_DeploymentConfig__deploymentconfigs_when_run_iteratively__Conformance__should_only_deploy_the_last_deployment__Suite_openshift_conformance_parallel_/

logs.txt

[sjenning]

https://openshift-gce-devel.appspot.com/build/origin-ci-test/pr-logs/pull/16896/test_pull_request_origin_extended_conformance_gce/9904/

[smarterclayton]

This was probably pushed over the edge into continuous failures by #16913 - we clean up pods faster, so the controller is more likely to race.

[smarterclayton]

Bumping priority since this is breaking most jobs - @tnozicka said he had recreated and is working on a fix.

[tnozicka]

@smarterclayton yes, that seem probable because it now waits for about 3s in terminating state and in the meantime we create a new RC and new deployer pod

[tnozicka]

temporarily disabling the check #16956

[tnozicka]

I thing this is just the check actually seeing 2 deployer pods in non terminating state although they aren't actually running. There seems to be a bug in kubelet updating pod phase from Succeeded to Pending #17011

[tnozicka]

It has been confirmed to be caused by #17011 which is now fixed