[
https://issues.apache.org/jira/browse/AIRFLOW-4393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16844055#comment-16844055
]
ASF subversion and git services commented on AIRFLOW-4393:
----------------------------------------------------------
Commit 3882beaf85579a26b0ce8b15d8ac3dc199e211bd in airflow's branch
refs/heads/master from Olivier Van Goethem
[ https://gitbox.apache.org/repos/asf?p=airflow.git;h=3882bea ]
[AIRFLOW-4393] Add exponential backoff retry (#5284)
> Add retry logic when fetching pod status and/or logs in KubernetesPodOperator
> -----------------------------------------------------------------------------
>
> Key: AIRFLOW-4393
> URL: https://issues.apache.org/jira/browse/AIRFLOW-4393
> Project: Apache Airflow
> Issue Type: Bug
> Reporter: Olivier Van Goethem
> Priority: Minor
>
> Over the last weeks we have observed 2 occasions where:
> * KubernetesPodOperator successfully launches the pod
> * KubernetesPodOperator then fails when attempting to check the pod
> status/logs due to:
> {code:java}
> NewConnectionError('<urllib3.connection.VerifiedHTTPSConnection object at
> 0x7f1329dc0cf8>: Failed to establish a new connection: [Errno 111] Connection
> refused',)
> {code}
> * KubernetesPodOperator launches another pod
> * We now have 2 pods running in parallel
> The cause for the 'Connection refused' is due to a transient network error.
> As such, the KubernetesPodOperator should attempt to retry checking the pod
> status/logs rather than failing the task.
> Airflow is being run through GCP's Cloud Composer.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
