Do not ask API server for a Pod during deletion unnecessarily

[jglick]

Not tested yet, but hoping this would avoid

java.net.SocketTimeoutException: connect timed out
        at java.base/java.net.PlainSocketImpl.socketConnect(Native Method)
        at …
        at java.base/java.net.Socket.connect(Socket.java:609)
        at okhttp3.internal.platform.Platform.connectSocket(Platform.java:129)
        at …
Caused: java.io.IOException: connect timed out
        at io.fabric8.kubernetes.client.dsl.internal.OperationSupport.waitForResult(OperationSupport.java:533)
        at io.fabric8.kubernetes.client.dsl.internal.OperationSupport.handleResponse(OperationSupport.java:570)
        at io.fabric8.kubernetes.client.dsl.internal.OperationSupport.handleGet(OperationSupport.java:482)
        at io.fabric8.kubernetes.client.dsl.internal.BaseOperation.handleGet(BaseOperation.java:742)
        at io.fabric8.kubernetes.client.dsl.internal.BaseOperation.getMandatory(BaseOperation.java:177)
Caused: io.fabric8.kubernetes.client.KubernetesClientException: Operation: [get]  for kind: [Pod]  with name: […]  in namespace: […]  failed.
        at io.fabric8.kubernetes.client.KubernetesClientException.launderThrowable(Kub
ernetesClientException.java:159)
        at io.fabric8.kubernetes.client.dsl.internal.BaseOperation.getMandatory(BaseOperation.java:182)
        at io.fabric8.kubernetes.client.dsl.internal.BaseOperation.get(BaseOperation.java:144)
        at io.fabric8.kubernetes.client.dsl.internal.BaseOperation.get(BaseOperation.java:93)
        at org.csanchez.jenkins.plugins.kubernetes.KubernetesSlave._terminate(KubernetesSlave.java:313)
        at …

Probably the actual deletion would fail later anyway, but why make two API calls when one suffices (assuming you have not actually configured OnFailure)?

[Vlatombe]

[offtopic] handleNonKubernetes: true feels weird, shouldn't the condition be renamed?

[jglick]

Well this is to handle the scenario on ci.jenkins.io where we are requesting a label which currently is handled by the kubernetes plugin but admins have left open the possibility of switching to some other cloud if performance merits it.

[Vlatombe]

rebuilding

[Vlatombe]

Flake

 16.155 [run In Pod With Restart With Multiple Container Calls #1] run-in-pod-with-restart-with-multiple-container-calls-1-2-przqw has been removed for 15 sec, assuming it is not coming back

would that cause ABORTED build status even though it seems the build is able to complete its steps ?

Related: jenkinsci/workflow-durable-task-step-plugin#180

Prior to that

   1.124 [run In Pod With Restart With Multiple Container Calls #1] Waiting for reconnection of run-in-pod-with-restart-with-multiple-container-calls-1-2-przqw before proceeding with build
  13.929 [id=194]	INFO	h.TcpSlaveAgentListener$ConnectionHandler#run: Connection #6 failed: java.io.EOFException
  14.047 [id=196]	INFO	h.TcpSlaveAgentListener$ConnectionHandler#run: Accepted JNLP4-connect connection #7 from /10.244.0.32:32956

Maybe 15 seconds here is a bit too short considering the 10 seconds delay between retries ? https://github.com/jenkinsci/remoting/blob/952d22bc5673950f53a949b49fbe1427d99324d9/src/main/java/hudson/remoting/Engine.java#L688

[jglick]

Maybe 15 seconds here is a bit too short

Probably; trying to make routine tests run in a reasonable amount of time. FYI jenkinsci/workflow-durable-task-step-plugin#284

[jglick]

FTR some other PRs related to pod deletion: #1095, #1227