-
Notifications
You must be signed in to change notification settings - Fork 14.6k
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
Enable pools to consider deferred tasks #32709
Enable pools to consider deferred tasks #32709
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)
|
5cc1eb0
to
a64938f
Compare
Rebased on |
airflow/migrations/versions/0128_2_7_0_add_include_deferred_column_to_pool.py
Outdated
Show resolved
Hide resolved
6a1d3b0
to
3c31c45
Compare
@@ -20,7 +20,7 @@ Deferrable Operators & Triggers | |||
|
|||
Standard :doc:`Operators </core-concepts/operators>` and :doc:`Sensors <../core-concepts/sensors>` take up a full *worker slot* for the entire time they are running, even if they are idle; for example, if you only have 100 worker slots available to run Tasks, and you have 100 DAGs waiting on a Sensor that's currently running but idle, then you *cannot run anything else* - even though your entire Airflow cluster is essentially idle. ``reschedule`` mode for Sensors solves some of this, allowing Sensors to only run at fixed intervals, but it is inflexible and only allows using time as the reason to resume, not anything else. | |||
|
|||
This is where *Deferrable Operators* come in. A deferrable operator is one that is written with the ability to suspend itself and free up the worker when it knows it has to wait, and hand off the job of resuming it to something called a *Trigger*. As a result, while it is suspended (deferred), it is not taking up a worker slot and your cluster will have a lot less resources wasted on idle Operators or Sensors. | |||
This is where *Deferrable Operators* come in. A deferrable operator is one that is written with the ability to suspend itself and free up the worker when it knows it has to wait, and hand off the job of resuming it to something called a *Trigger*. As a result, while it is suspended (deferred), it is not taking up a worker slot and your cluster will have a lot less resources wasted on idle Operators or Sensors. Note that by default a deferred tasks will not use up a pool slot, if you would like them to, you can change this by editing the pool in question. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Typo in the following sentence ("task" should be singular)
Note that by default a deferred task
swill not use up a pool slot, if you would like them to, you can change this by editing the pool in question.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oops, fixed by making everything plural
3c31c45
to
20460d5
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder if we could add some help text in the pool form to explain what the flag means, it’s not as straightfoward as other fields. I’m not sure how to do that though, probably via some WTForm trick.
airflow/migrations/versions/0128_2_7_0_add_include_deferred_column_to_pool.py
Outdated
Show resolved
Hide resolved
Looks like Flask AppBuilder has a feature for that. I'm open for suggestions if someone has a better help text: |
I think you also need to remove the required marker on the checkbox field (not sure how), otherwise the form would not allow the box to be unchecked. |
Ah, that explains why the test is failing. Could have sworn I ran this test before, but neglected to run it again after changing the column to I would tend to revert that decision and instead make the column nullable with a default similar to |
Making it nullable would cause the unchecked case to return NULL instead of FALSE, which is not a good idea. NULL in SQL is just bad. I’m pretty sure there’s a way to make a checkbox return true/false instead. |
20460d5
to
8ce2737
Compare
OK, managed to get it working by overriding the form field. Using an additional validator in |
8186261
to
c0827b3
Compare
Couple of places that break due to having no default value. I'll fix those and push once the full test suite completes locally. Sorry for that! |
…port backwards compatible
0965969
to
8131f43
Compare
Tests are failing:
|
Yeah. My bad. In fact the client is still used internally by pool command it seems. So yeah. My change was too much - will remove it and only remove stuff from experimental client |
8131f43
to
260d51e
Compare
Re-pushed original change - the back compatibiliyt is not needed there and the change was good as it was! I completely forgot that we used to use the "CLI API" before - but it's really not part of the public API since 2.0 |
Let's just run tests again after rebase and merge it. |
Awesome work, congrats on your first merged pull request! You are invited to check our Issue Tracker for additional contributions. |
We should change the defaults to client defaults for MSSQL compatibility The change in apache#32709 was not liked by MSSQL
We should change the defaults to client defaults for MSSQL compatibility The change in #32709 was not liked by MSSQL Co-authored-by: Ephraim Anierobi <splendidzigy24@gmail.com>
* Makes pools respect deferrable tasks (with extra setting) See #21243 This commit makes pools consider deferred tasks if the `include_deferred` flag is set. By default a pool will not consider deferred tasks as occupied slots, but still show the number of deferred tasks in its stats. --------- Co-authored-by: Tzu-ping Chung <uranusjr@gmail.com> (cherry picked from commit 70a050b)
closes: #21243
This is my attempt at solving the issue raised in the linked discussion. With this change we would introduce a new flag on
Pool
, that allows an admin to decide whether to include tasks in deferred state in the pool open slot calculation or not. By default we would not consider them, which mirrors the current behavior.As mentioned by various people on the discussion, having this as an option can be quite useful, especially in cases where the system that is "shielded" by the pool is not completely in the control of the developer. This allows us to (mis)use pools as a rate-limiting device even when using the new deferrable operators.