-
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
Some liveness checks don't actually check process #26574
Comments
Thanks for opening your first issue here! Be sure to follow the issue template! |
Marked it as good first issue, this is a good idea, and hopefully someone might improve it. BTW. @nsAstro - If you have ideas how to improve - you are most welcome to make PR #- this is an easy way to become one of the ~ 2200 contributors. Otherwise it will just have to wait for someone to pick it up. |
@potiuk, I would like to take this task. Can you please assign it to me? |
@potiuk, Can I take this task? |
@uranusjr, Thanks! I have started working on it. |
@uranusjr @TruptiM18 if you aren't working on this, I would like to try my hand at it. |
Please feel free. |
Thanks. Any hints or clues on what we are looking to have as new liveness probes? @uranusjr |
Description
Current liveness check probes use the 'airflow jobs' command which directly queries the backend DB as opposed to actually querying an endpoint or checking the status of the process itself.
e.g. Triggerer liveness probe
This command only checks the backend DB to see if there are any jobs. Additionally, the exit code is always 0 regardless of how many jobs there are. Ideally, the liveness check is done by querying some endpoint on the triggerer to see if it's still running.
Use case/motivation
Would like a liveness check that is more aware of the process rather than the stored state
Related issues
No response
Are you willing to submit a PR?
Code of Conduct
The text was updated successfully, but these errors were encountered: