-
Notifications
You must be signed in to change notification settings - Fork 14.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix(helm): dagprocessor livenessProbe include --local and --job-type args #32426
Conversation
Congratulations on your first Pull Request and welcome to the Apache Airflow community! If you have any issues or are unsure about any anything please check our Contribution Guide (https://github.com/apache/airflow/blob/main/CONTRIBUTING.rst)
|
I think you will also need to add / modify some of the "helm_tests" of ours |
You might want to rebase to latest main - just merged a change to move them to "helm_tests" directory |
ace569b
to
c605f11
Compare
Added a test case for this livenessProbe. |
Would be great! |
@potiuk tests added, let me know if there's anything more I can/need to do |
Awesome work, congrats on your first merged pull request! You are invited to check our Issue Tracker for additional contributions. |
As of Airflow 2.5.0, the
--local
argument was introduced to theairflow jobs check
command.Without this argument, when a user has redefined the following configuration:
The livenessProbes using the command would fail due to "No alive jobs found", since the
$(hostname)
value may not align with what was set inhostname_callable
.As of Airflow 2.5.2, there is now also a
DagProcessorJob
job type which can be additionally checked for, to ensure that the livenessProbes do not incorrectly validate different Jobs on the same host as counting towards the dagprocessor being aliveDISCLAIMER: the Helm template in this PR deviates from the existing probe templates, to avoid unnecessary duplication. This refactoring can also be applied to the
scheduler_liveness_check_command
andtriggerer_liveness_check_command
if that is requested.Inversely, I can also refactor to comply with the existing if/else duplication of the templates.
related: #28799
Read the Pull Request Guidelines for more information.
In case of fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
In case of a new dependency, check compliance with the ASF 3rd Party License Policy.
In case of backwards incompatible changes please leave a note in a newsfragment file, named
{pr_number}.significant.rst
or{issue_number}.significant.rst
, in newsfragments.