jscheffl commented on code in PR #49784:
URL: https://github.com/apache/airflow/pull/49784#discussion_r2083515014
##########
providers/cncf/kubernetes/src/airflow/providers/cncf/kubernetes/utils/pod_manager.py:
##########
@@ -375,30 +376,54 @@ def create_pod(self, pod: V1Pod) -> V1Pod:
return self.run_pod_async(pod)
def await_pod_start(
- self, pod: V1Pod, startup_timeout: int = 120, startup_check_interval:
int = 1
+ self, pod: V1Pod, schedule_timeout: int = 120, startup_timeout: int =
120, check_interval: int = 1
) -> None:
"""
Wait for the pod to reach phase other than ``Pending``.
:param pod:
+ :param schedule_timeout: Timeout (in seconds) for pod stay in schedule
state
+ (if pod is taking to long in schedule state, fails task)
:param startup_timeout: Timeout (in seconds) for startup of the pod
- (if pod is pending for too long, fails task)
- :param startup_check_interval: Interval (in seconds) between checks
+ (if pod is pending for too long after being scheduled, fails task)
+ :param check_interval: Interval (in seconds) between checks
:return:
"""
+ self.log.info("::group::Waiting until %ss to get the POD
scheduled...", schedule_timeout)
+ pod_was_scheduled = False
Review Comment:
atm the variable seems to be only used to emit the logs. But it should be
used (in my view) rather to check against the different timeouts.
The variable `curr_time` is in the changed context a bit mis-leading. Maybe
you can find a better name aking clear that this is the starting point from
which timeout is checked.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscr...@airflow.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
