You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@airflow.apache.org by "SameerMesiah97 (via GitHub)" <gi...@apache.org> on 2026/02/08 12:23:35 UTC
[PR] Add delete_pods_in_phase override to KubernetesPodOperator [airflow]
SameerMesiah97 opened a new pull request, #61637:
URL: https://github.com/apache/airflow/pull/61637
**Description**
This change introduces a new optional parameter, `delete_pods_in_phase`, to `KubernetesPodOperator` that allows pod deletion to be controlled explicitly by Kubernetes pod phase.
When `delete_pods_in_phase` is provided, the operator deletes a pod only if its current phase matches one of the configured values. In this mode, pod deletion is determined solely by phase and takes precedence over `on_finish_action`. This behavior is applied consistently across all pod-cleanup paths, including normal execution, failure handling, and duplicate-label pod resolution.
When the override is enabled, the operator emits an informational log message during initialization to make the precedence over `on_finish_action` explicit in task logs.
**Rationale**
Recent changes to `on_finish_action` have introduced or proposed additional pod-deletion modes, such as `delete_active_pod` (PR #59160) and `delete_non_failed_pod` (PR #59413), to support more nuanced cleanup behavior.
Rather than continuing to add new high-level `on_finish_action` values for each possible combination of pod phases, this change introduces a more general and explicit mechanism for advanced users. The `delete_pods_in_phase` parameter allows users to specify exactly which Kubernetes pod phases should trigger deletion, avoiding ambiguity and removing the need to debate or encode specific phase combinations into new modes.
This approach maximizes configurability while preserving existing semantics and keeping default behavior unchanged.
**Documentation**
A docstring has been added to `process_pod_deletion` describing the deletion decision flow and documenting the precedence of `delete_pods_in_phase` over `on_finish_action`.
**Notes**
* Patching logic has been made more explicit to reflect whether a pod was intentionally retained due to phase-based deletion rules.
* Duplicate-label pod handling has been updated to respect `delete_pods_in_phase`, ensuring consistent cleanup behavior when multiple pods share identical task labels.
**Tests**
Added unit tests that:
* Verify that `delete_pods_in_phase` overrides `on_finish_action` when determining whether a pod should be deleted.
* Update existing cleanup tests to cover phase-based deletion and patching behavior when deletion does not occur.
* Validate input normalization and error handling for `delete_pods_in_phase` values.
**Backwards Compatibility**
When `delete_pods_in_phase` is not provided, pod deletion behavior remains unchanged and continues to be governed exclusively by `on_finish_action`. No existing defaults are modified, and no public APIs are removed or altered besides the addition of the `delete_pods_in_phase` parameter.
--
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: commits-unsubscribe@airflow.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] Add delete_pods_in_phase override to KubernetesPodOperator [airflow]
Posted by "potiuk (via GitHub)" <gi...@apache.org>.
potiuk commented on PR #61637:
URL: https://github.com/apache/airflow/pull/61637#issuecomment-4476902596
@SameerMesiah97 — Removing the `ready for maintainer review` label and converting back to draft. **The branch now has merge conflicts with `main`** that surfaced after the label was added.
The label's contract is that the PR is ready for maintainer review — a regression like this means the PR temporarily isn't. Rebase your branch onto the latest `main`, resolve conflicts, then mark "Ready for review" again to re-enter the queue.
`git fetch upstream main && git rebase upstream/main`, resolve, `git push --force-with-lease`. See the [working-with-git docs](https://github.com/apache/airflow/blob/main/contributing-docs/10_working_with_git.rst).
No rush.
---
_Note: This comment was drafted by an AI-assisted triage tool and may contain mistakes. Once you have addressed the points above, an Apache Airflow maintainer — a real person — will take the next look at your PR. We use this [two-stage triage process](https://github.com/apache/airflow/blob/main/contributing-docs/25_maintainer_pr_triage.md#why-the-first-pass-is-automated) so that our maintainers' limited time is spent where it matters most: the conversation with you._
--
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: commits-unsubscribe@airflow.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] Add delete_pods_in_phase override to KubernetesPodOperator [airflow]
Posted by "potiuk (via GitHub)" <gi...@apache.org>.
potiuk commented on PR #61637:
URL: https://github.com/apache/airflow/pull/61637#issuecomment-4617784634
@SameerMesiah97 This draft PR has been inactive for 17 days since the last triage comment and no response from the author. Closing to keep the queue clean.
You are welcome to reopen this PR when you resume work, or to open a new one addressing the issues previously raised. There is no rush — take your time.
---
_Note: This comment was drafted by an AI-assisted triage tool and may contain mistakes. Once you resume work, an Apache Airflow maintainer — a real person — will take the next look at your PR. We use this [two-stage triage process](https://github.com/apache/airflow/blob/main/contributing-docs/25_maintainer_pr_triage.md#why-the-first-pass-is-automated) so that our maintainers' limited time is spent where it matters most: the conversation with you._
--
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: commits-unsubscribe@airflow.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] Add delete_pods_in_phase override to KubernetesPodOperator [airflow]
Posted by "Nataneljpwd (via GitHub)" <gi...@apache.org>.
Nataneljpwd commented on code in PR #61637:
URL: https://github.com/apache/airflow/pull/61637#discussion_r2837220085
##########
providers/cncf/kubernetes/src/airflow/providers/cncf/kubernetes/operators/pod.py:
##########
@@ -457,6 +466,29 @@ def __init__(
self.container_name_log_prefix_enabled = container_name_log_prefix_enabled
self.log_formatter = log_formatter
+ @staticmethod
+ def _validate_delete_pods_in_phase(delete_pods_in_phase: Iterable[str] | str) -> set[str]:
+ if isinstance(delete_pods_in_phase, str):
+ phases = {delete_pods_in_phase}
+ else:
+ phases = set(delete_pods_in_phase)
+
+ valid_phases = {
+ PodPhase.PENDING,
+ PodPhase.RUNNING,
+ PodPhase.FAILED,
+ PodPhase.SUCCEEDED,
+ PodPhase.UNKNOWN,
+ }
+
+ invalid = phases - valid_phases
+ if invalid:
+ raise AirflowException(
+ f"Invalid pod phase(s) in delete_pods_in_phase: {sorted(invalid)}. Valid phases are: Pending, Running, Failed, Succeeded, Unknown."
+ )
+
+ return phases
Review Comment:
Should a validation method return the object it validates against? It seems weird to me to return the exact same object you receive if when invalid we throw an exception and return nothing
##########
providers/cncf/kubernetes/src/airflow/providers/cncf/kubernetes/operators/pod.py:
##########
@@ -1238,11 +1303,11 @@ def process_pod_deletion(self, pod: k8s.V1Pod, *, reraise=True) -> bool:
)
)
- if should_delete_pod:
- self.log.info("Deleting pod: %s", pod.metadata.name)
- self.pod_manager.delete_pod(pod)
- return True
- self.log.info("Skipping deleting pod: %s", pod.metadata.name)
+ if should_delete_pod:
+ self.log.info("Deleting pod: %s", pod.metadata.name)
+ self.pod_manager.delete_pod(pod)
+ return True
+ self.log.info("Skipping deleting pod: %s", pod.metadata.name)
return False
Review Comment:
Usually when I have a boolean object, I return it instead of returning its value checked in an if, and avoid returning early in this case, as of now I can't think of a way for this to be done here, what do you think?
--
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: commits-unsubscribe@airflow.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] Add delete_pods_in_phase override to KubernetesPodOperator [airflow]
Posted by "SameerMesiah97 (via GitHub)" <gi...@apache.org>.
SameerMesiah97 commented on PR #61637:
URL: https://github.com/apache/airflow/pull/61637#issuecomment-3921072608
@jscheffl
I was hoping you could help with review. No pressure.
--
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: commits-unsubscribe@airflow.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] Add delete_pods_in_phase override to KubernetesPodOperator [airflow]
Posted by "jscheffl (via GitHub)" <gi...@apache.org>.
jscheffl commented on PR #61637:
URL: https://github.com/apache/airflow/pull/61637#issuecomment-3940593076
I am unsure about if it is really a good idea to add a second parameter with additional complexity in logic if there is already one which is (known not be be perfect but already covers 90%). I think adding another second method adds also mental load for users to understand as well as is a risk of inconsistency.
As there are many users using K8s I am a bit afraid that such change on a "public API" is more costly than the benefits gained. Therefore I was stepping a bit back waiting for other feedback. Still am not really convinced and would ask if other maintainers see a larger benefit - then I'd not block the merge. In a classic vote in devlist I'd give a "0" (not -1 and no +1)
--
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: commits-unsubscribe@airflow.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] Add delete_pods_in_phase override to KubernetesPodOperator [airflow]
Posted by "potiuk (via GitHub)" <gi...@apache.org>.
potiuk commented on PR #61637:
URL: https://github.com/apache/airflow/pull/61637#issuecomment-4111949872
@SameerMesiah97 This PR has a few issues that need to be addressed before it can be reviewed — please see our [Pull Request quality criteria](https://github.com/apache/airflow/blob/main/contributing-docs/05_pull_requests.rst#pull-request-quality-criteria).
**Issues found:**
- :x: **Merge conflicts**: This PR has merge conflicts with the `main` branch. Your branch is 1190 commits behind `main`. Please rebase your branch (`git fetch origin && git rebase origin/main`), resolve the conflicts, and push again. See [contributing quick start](https://github.com/apache/airflow/blob/main/contributing-docs/03a_contributors_quick_start_beginners.rst).
> **Note:** Your branch is **1190 commits behind `main`**. Some check failures may be caused by changes in the base branch rather than by your PR. Please rebase your branch and push again to get up-to-date CI results.
**What to do next:**
- The comment informs you what you need to do.
- Fix each issue, then mark the PR as "Ready for review" in the GitHub UI - but only after making sure that all the issues are fixed.
- There is no rush — take your time and work at your own pace. We appreciate your contribution and are happy to wait for updates.
- Maintainers will then proceed with a normal review.
There is no rush — take your time and work at your own pace. We appreciate your contribution and are happy to wait for updates. If you have questions, feel free to ask on the [Airflow Slack](https://s.apache.org/airflow-slack).
--
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: commits-unsubscribe@airflow.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] Add delete_pods_in_phase override to KubernetesPodOperator [airflow]
Posted by "jscheffl (via GitHub)" <gi...@apache.org>.
jscheffl commented on PR #61637:
URL: https://github.com/apache/airflow/pull/61637#issuecomment-4049727746
> > > @jscheffl
> > > I was hoping you could respond to my comment proposing a refinement to the approach i.e. turning this from an override parameter to an additional enumeration. If this is acceptable, I can proceed.
> >
> >
> > Sorry, I was distracted the last weeks at work and kept my review work at minimum. Therefore also lagging "creative" moments for further ideas. I am a bit conservative on interfaces and changes, especially as KPO is so widely used. So my hope was some other maintainer has more feedback or opinions.
> > If you force me to an opinion: I do not have a problem with the current selection and even if in theory there are 31 options I think in my use cases I thought of I am not missing any. But you can convince me of a use case not covered. Else I know how hard it is for people to use Airflow and I am fearing more of problems of mental load and complexity with less benefit. Except if there is a use case...
>
> Okay. So, in other words, you feel that it is not worthwhile even as an additional enum? Is that correct? If that is the case, what should become of this PR? Should we leave it open for other maintainers to weigh in? Or just close it?
We are a community and I have an opinion but it is fair that other people / maintainers have other opinions. Therefore I'd leave it open for other opinons --> @potiuk / @jedcunningham / @hussein-awala - WDYT? I am +0 on this.
--
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: commits-unsubscribe@airflow.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] Add delete_pods_in_phase override to KubernetesPodOperator [airflow]
Posted by "SameerMesiah97 (via GitHub)" <gi...@apache.org>.
SameerMesiah97 commented on PR #61637:
URL: https://github.com/apache/airflow/pull/61637#issuecomment-4046556315
@jscheffl
I was hoping you could respond to my comment proposing a refinement to the approach i.e. turning this from an override parameter to an additional enumeration. If this is acceptable, I can proceed.
@potiuk
I was curious about your thoughts on this as well. Since you were involved in the discussion in PR #59413.
--
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: commits-unsubscribe@airflow.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] Add delete_pods_in_phase override to KubernetesPodOperator [airflow]
Posted by "jscheffl (via GitHub)" <gi...@apache.org>.
jscheffl commented on PR #61637:
URL: https://github.com/apache/airflow/pull/61637#issuecomment-4049414667
> @jscheffl
>
> I was hoping you could respond to my comment proposing a refinement to the approach i.e. turning this from an override parameter to an additional enumeration. If this is acceptable, I can proceed.
Sorry, I was distracted the last weeks at work and kept my review work at minimum. Therefore also lagging "creative" moments for further ideas. I am a bit conservative on interfaces and changes, especially as KPO is so widely used. So my hope was some other maintainer has more feedback or opinions.
If you force me to an opinion: I do not have a problem with the current selection and even if in theory there are 31 options I think in my use cases I thought of I am not missing any. But you can convince me of a use case not covered. Else I know how hard it is for people to use Airflow and I am fearing more of problems of mental load and complexity with less benefit. Except if there is a use case...
--
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: commits-unsubscribe@airflow.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] Add delete_pods_in_phase override to KubernetesPodOperator [airflow]
Posted by "Nataneljpwd (via GitHub)" <gi...@apache.org>.
Nataneljpwd commented on PR #61637:
URL: https://github.com/apache/airflow/pull/61637#issuecomment-3955000044
> I am unsure about if it is really a good idea to add a second parameter with additional complexity in logic if there is already one which is (known not be be perfect but already covers 90%). I think adding another second method adds also mental load for users to understand as well as is a risk of inconsistency.
I agree about the mental load, the method is quite complex (due to the mix of on_finish actions), maybe it can be done in a different place to reduce the mental load by offloading from the given method, I agree that there are not too many use cases for it, but they do exist, maybe even making an on finish action of delete by phase could make the code much lighter for the reader, what do you think?
> As there are many users using K8s I am a bit afraid that such change on a "public API" is more costly than the benefits gained. Therefore I was stepping a bit back waiting for other feedback. Still am not really convinced and would ask if other maintainers see a larger benefit - then I'd not block the merge. In a classic vote in devlist I'd give a "0" (not -1 and no +1)
I can see the point here, where the change might outweigh the benefit, if the feature is indeed needed, it is possible to either simplify the change or increase the benefit of the feature (which I don't know how this can be done)
--
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: commits-unsubscribe@airflow.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] Add delete_pods_in_phase override to KubernetesPodOperator [airflow]
Posted by "Nataneljpwd (via GitHub)" <gi...@apache.org>.
Nataneljpwd commented on code in PR #61637:
URL: https://github.com/apache/airflow/pull/61637#discussion_r2849753016
##########
providers/cncf/kubernetes/src/airflow/providers/cncf/kubernetes/operators/pod.py:
##########
@@ -442,6 +446,11 @@ def __init__(
self.remote_pod: k8s.V1Pod | None = None
self.log_pod_spec_on_failure = log_pod_spec_on_failure
self.on_finish_action = OnFinishAction(on_finish_action)
+
+ self.delete_pods_in_phase = (
+ self._validate_delete_pods_in_phase(delete_pods_in_phase) if delete_pods_in_phase else None
Review Comment:
Looks weird
Why not
```python
delete_pods_in_phase if _validate_delete_pods_in_phase(delete_pods_in_phase) else None
```
--
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: commits-unsubscribe@airflow.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] Add delete_pods_in_phase override to KubernetesPodOperator [airflow]
Posted by "potiuk (via GitHub)" <gi...@apache.org>.
potiuk closed pull request #61637: Add delete_pods_in_phase override to KubernetesPodOperator
URL: https://github.com/apache/airflow/pull/61637
--
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: commits-unsubscribe@airflow.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] Add delete_pods_in_phase override to KubernetesPodOperator [airflow]
Posted by "SameerMesiah97 (via GitHub)" <gi...@apache.org>.
SameerMesiah97 commented on PR #61637:
URL: https://github.com/apache/airflow/pull/61637#issuecomment-3940951284
> I am unsure about if it is really a good idea to add a second parameter with additional complexity in logic if there is already one which is (known not be be perfect but already covers 90%). I think adding another second method adds also mental load for users to understand as well as is a risk of inconsistency.
>
> As there are many users using K8s I am a bit afraid that such change on a "public API" is more costly than the benefits gained. Therefore I was stepping a bit back waiting for other feedback. Still am not really convinced and would ask if other maintainers see a larger benefit - then I'd not block the merge. In a classic vote in devlist I'd give a "0" (not -1 and no +1)
The motivation behind this change comes from the discussion in PR #59413, where there was considerable back and forth around which pod phases should be deleted under each enum. While the existing `on_finish_action `parameter is functional and covers most use cases, that thread highlighted how users could prefer different phase groupings for deletion depending on their individual setups.
Since Kubernetes defines five pod phases, there are 31 possible non-empty combinations. Encoding specific combinations as additional enums over time could lead to repeated discussions about which groupings should or should not be supported. The intention here is not to replace the existing modes, but to provide a clearly named and optional escape hatch for cases that fall outside the common patterns. This would allow users who require a specific phase combination to configure it explicitly, while keeping the existing enums unchanged and recommended for most scenarios.
I do agree that we should limit additional complexity. To mitigate that, I could refine the PR so that `'delete_pods_in_phase'` is an additional enum for `on_finish_action `rather than an override parameter. The new parameter `delete_pods_in_phase` could instead be used to set the phases of the pods to be deleted. As a result of this modification, this PR would not be adding a new parameter but extending the list of options for `on_finish_action`, which I believe would be less disruptive.
--
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: commits-unsubscribe@airflow.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] Add delete_pods_in_phase override to KubernetesPodOperator [airflow]
Posted by "SameerMesiah97 (via GitHub)" <gi...@apache.org>.
SameerMesiah97 commented on PR #61637:
URL: https://github.com/apache/airflow/pull/61637#issuecomment-4049450387
> > @jscheffl
> > I was hoping you could respond to my comment proposing a refinement to the approach i.e. turning this from an override parameter to an additional enumeration. If this is acceptable, I can proceed.
>
> Sorry, I was distracted the last weeks at work and kept my review work at minimum. Therefore also lagging "creative" moments for further ideas. I am a bit conservative on interfaces and changes, especially as KPO is so widely used. So my hope was some other maintainer has more feedback or opinions.
>
> If you force me to an opinion: I do not have a problem with the current selection and even if in theory there are 31 options I think in my use cases I thought of I am not missing any. But you can convince me of a use case not covered. Else I know how hard it is for people to use Airflow and I am fearing more of problems of mental load and complexity with less benefit. Except if there is a use case...
Okay. So, in other words, you feel that it is worthwhile even as an additional enum? Is that correct? If that is the case, what should become of this PR? Should we leave it open for other maintainers to weigh in? Or just close it?
--
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: commits-unsubscribe@airflow.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] Add delete_pods_in_phase override to KubernetesPodOperator [airflow]
Posted by "SameerMesiah97 (via GitHub)" <gi...@apache.org>.
SameerMesiah97 commented on PR #61637:
URL: https://github.com/apache/airflow/pull/61637#issuecomment-4112021515
@potiuk
The PR is currently stalled pending maintainer consensus. @jscheffl is on the fence and has requested other maintainers (including you) to provide their thoughts on the PR.
--
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: commits-unsubscribe@airflow.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] Add delete_pods_in_phase override to KubernetesPodOperator [airflow]
Posted by "potiuk (via GitHub)" <gi...@apache.org>.
potiuk commented on PR #61637:
URL: https://github.com/apache/airflow/pull/61637#issuecomment-4106845131
@SameerMesiah97 This PR has a few issues that need to be addressed before it can be reviewed — please see our [Pull Request quality criteria](https://github.com/apache/airflow/blob/main/contributing-docs/05_pull_requests.rst#pull-request-quality-criteria).
**Issues found:**
- :x: **Merge conflicts**: This PR has merge conflicts with the `main` branch. Your branch is 1168 commits behind `main`. Please rebase your branch (`git fetch origin && git rebase origin/main`), resolve the conflicts, and push again. See [contributing quick start](https://github.com/apache/airflow/blob/main/contributing-docs/03a_contributors_quick_start_beginners.rst).
> **Note:** Your branch is **1168 commits behind `main`**. Some check failures may be caused by changes in the base branch rather than by your PR. Please rebase your branch and push again to get up-to-date CI results.
**What to do next:**
- The comment informs you what you need to do.
- Fix each issue, then mark the PR as "Ready for review" in the GitHub UI - but only after making sure that all the issues are fixed.
- There is no rush — take your time and work at your own pace. We appreciate your contribution and are happy to wait for updates.
- Maintainers will then proceed with a normal review.
There is no rush — take your time and work at your own pace. We appreciate your contribution and are happy to wait for updates. If you have questions, feel free to ask on the [Airflow Slack](https://s.apache.org/airflow-slack).
--
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: commits-unsubscribe@airflow.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org