-
Notifications
You must be signed in to change notification settings - Fork 14.5k
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
Update python.rst with multi-Scheduler LocalExecutor info #32310
Conversation
This PR updates the PythonOperator section of the documentation to include information about how the LocalExecutor works when multiple Airflow Schedulers are in use. In the updated documentation, I have added a note that explains: Each Scheduler, when configured with executor = LocalExecutor, runs its own LocalExecutor. Tasks are processed in a distributed fashion across the machines running the Schedulers. It takes into consideration the scenario when a scheduler is restarted. It also explains the limitations on sharing of instances across tasks with multiple Schedulers. This information was not clear in the existing documentation, and this update should help users understand how LocalExecutor works in a multi-Scheduler setup.
@@ -28,6 +28,16 @@ Use the ``@task`` decorator to execute Python callables. | |||
The ``@task`` decorator is recommended over the classic :class:`~airflow.operators.python.PythonOperator` | |||
to execute Python callables. | |||
|
|||
.. note:: |
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.
Why here? It is importand and valid potint to mention but it works the same way for every other operator, so I guess it should be explained in https://airflow.apache.org/docs/apache-airflow/stable/core-concepts/executor/local.html#local-executor
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.
@potiuk I missed that. I have made the changes in local.rst now. Let me know if that looks good
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.
@potiuk Updated now
|
||
.. note:: | ||
|
||
When using the ``@task`` decorator with multiple Schedulers configured with ``executor = LocalExecutor`` in the [core] section of airflow.cfg, each scheduler will run a LocalExecutor. This means tasks would be processed in a distributed fashion across the machines running the Schedulers. |
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.
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.
My understanding is that it is general
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.
@pankajkoti Updated and done
Co-authored-by: Pankaj Koti <[email protected]> (cherry picked from commit e53320d)
This PR updates the PythonOperator section of the documentation to include information about how the LocalExecutor works when multiple Airflow Schedulers are in use.
In the updated documentation, I have added a note that explains:
Each Scheduler, when configured with executor = LocalExecutor, runs its own LocalExecutor. Tasks are processed in a distributed fashion across the machines running the Schedulers. It takes into consideration the scenario when a scheduler is restarted. It also explains the limitations on sharing of instances across tasks with multiple Schedulers. This information was not clear in the existing documentation, and this update should help users understand how LocalExecutor works in a multi-Scheduler setup.
closes: #26565
related: #26565
^ Add meaningful description above
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.