insomnes commented on issue #47939:
URL: https://github.com/apache/airflow/issues/47939#issuecomment-2742629916
@jason810496 while working on this one I've found that we also use default
timers from helm chart for k8s checks on pods like this one on scheduler:
```
│ Startup: exec [sh -c CONNECTION_CHECK_MAX_COUNT=0
AIRFLOW__LOGGING__LOGGING_LEVEL=ERROR exec /entrypoint \
│
│ airflow jobs check --job-type SchedulerJob --local
│
│ ] delay=0s timeout=20s period=10s #success=1 #failure=6
```
What do you think about tuning them? Would it be reasonable regarding the
test suite speed up and k8s tests stability?
I think we can achieve minor gains on such checks by introducing a delay of
5 seconds and lowering the startup probe's period and timeout because they are
quite high for the local kind cluster environment.
I am also a bit puzzled by this test:
```python
@pytest.mark.parametrize("active_deadline_seconds", [10, 20])
def test_kubernetes_pod_operator_active_deadline_seconds(self,
active_deadline_seconds):
```
I think we can check it with lower timeouts and even only once, `reason` for
the pod status would be enough. These two tests are the longest in the pod
operator test suite.
Should I try to open separate PR on these to check?
--
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: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
