Definitely a +1 to this idea.
Will take a look at the draft PR shortly.
Thanks & Regards,
Amogh Desai
On Fri, Feb 14, 2025 at 5:27 AM Igor Kholopov
wrote:
> Definitely +1, AIP-85 can also greatly benefit from this, e.g. for
> event-based DAG processing
>
> On Fri, Feb 14, 2025 at 12:31 AM Vik
Thanks for sparking this discussion, Karen.
+1 to the idea of nuking "zombies". It is a term that requires some deep
understanding and also
is a term that can be misunderstood too: zombie tasks vs zombie processes.
However, this would affect users who are currently using this config, so as
others
Good job Utkarsh, Jed and team for the timely alphas!
Also loving the progressive reduction of incomplete work items every week :)
Thanks & Regards,
Amogh Desai
On Fri, Feb 14, 2025 at 2:05 AM Jarek Potiuk wrote:
> Yeah. God stuff :)
>
> On Thu, Feb 13, 2025 at 9:13 PM Vikram Koka
> wrot
Absolutely!
These foundations and a trustworthy group of people who we call the
community takes time to build
and everyone's time and effort is also very important.
Really blessed to be part of something like this :)
Thanks & Regards,
Amogh Desai
On Tue, Feb 11, 2025 at 4:09 AM Jarek Potiuk
Hello folks!
Multiple Executor Configuration (aka hybrid executors, AIP-61) has been out a
while now and we haven't had many issues with it. I'm proposing we mark it as
stable.
Relatedly I would also like to discuss removing support for the older hardcoded
hybrid executors (e.g. CeleryKubernet
Definitely +1, AIP-85 can also greatly benefit from this, e.g. for
event-based DAG processing
On Fri, Feb 14, 2025 at 12:31 AM Vikram Koka
wrote:
> Thanks for the quick feedback, team!
>
> Shubham,
> In response to your question about Notifier,
> I was in two minds about it, but I did include th
Thanks for the quick feedback, team!
Shubham,
In response to your question about Notifier,
I was in two minds about it, but I did include the
"MsgQueuePublishOperator" as a specific Operator for that particular
reason.
I will update the example to be explicit.
On Thu, Feb 13, 2025 at 3:17 PM
+1 and looking forward that I have time to read the PR... (not today...
but the next days!)
On 13.02.25 08:09, Jarek Potiuk wrote:
+1 for sure. This is a great idea.
On Thu, Feb 13, 2025 at 5:40 AM Ben Tallman wrote:
+1 for sure!
Thanks,
Ben
--
Ben Tallman - 503.680.5709
On Wed, Feb 12,
+1
On Thu, 13 Feb 2025 at 17:31, Constance Martineau
wrote:
> +1 Excited to see this
>
> On Thu, Feb 13, 2025 at 11:01 AM Pierre Jeambrun
> wrote:
>
> > +1
> >
> > On Thu, Feb 13, 2025 at 4:36 PM Vincent Beck
> wrote:
> >
> > > Hi Vikram,
> > >
> > > Thanks for putting it together, I think thi
Yeah. God stuff :)
On Thu, Feb 13, 2025 at 9:13 PM Vikram Koka
wrote:
> Utkarsh and Jed,
>
> Thank you for publishing this as scheduled.
> Great way to follow through on the "If it hurts, do it more often"
> principle.
>
> It is great to see the list of "open items" reduced in each alpha.
>
Utkarsh and Jed,
Thank you for publishing this as scheduled.
Great way to follow through on the "If it hurts, do it more often"
principle.
It is great to see the list of "open items" reduced in each alpha.
Thank you to all the contributors, great job!
Best regards,
Vikram
On Thu, Feb 13, 2025
Yes, I understand that heartbeat is applicable here, which is why I was only
against 1 of the name change.
"task_instance_heartbeat_timeout*" is definitely easier to follow and
contextualize as compared to keeping scheduler prefix.
Shubham
On 2025-02-13, 9:18 AM, "Ryan Hatter" mailto:ryan.h
Dear Airflow Community,
I am thrilled to announce the availability of *Apache Airflow 3.0.0.alpha3*
for testing! Airflow 3.0 marks a significant milestone as the first major
release in over four years, introducing improvements that enhance user
experience, task execution, and system scalability.
F
>
> Tbh "heartbeat" itself is an overused term/concept in Airflow. I think we
> already have 6 configurations with "heartbeat" in it, and they're different
> types of heartbeats.
Anyways, I am against this name change:
> scheduler_zombie_task_threshold -->
> scheduler_task_heartbeat_timeout_thr
+1 Excited to see this
On Thu, Feb 13, 2025 at 11:01 AM Pierre Jeambrun
wrote:
> +1
>
> On Thu, Feb 13, 2025 at 4:36 PM Vincent Beck wrote:
>
> > Hi Vikram,
> >
> > Thanks for putting it together, I think this is great and will help users
> > to use event driven scheduling in Airflow 3!
> >
> >
+1
On Thu, Feb 13, 2025 at 4:36 PM Vincent Beck wrote:
> Hi Vikram,
>
> Thanks for putting it together, I think this is great and will help users
> to use event driven scheduling in Airflow 3!
>
> On 2025/02/13 08:10:05 "Mehta, Shubham" wrote:
> > +1
> >
> > We should also consider extending thi
Hi Vikram,
Thanks for putting it together, I think this is great and will help users to
use event driven scheduling in Airflow 3!
On 2025/02/13 08:10:05 "Mehta, Shubham" wrote:
> +1
>
> We should also consider extending this abstraction to Airflow publishing
> (such as notifier use cases). H
I like the proposal. Can't really disagree with people voluntarily taking
ownership of specific aspects of the codebase.
Given the complexity of Airflow, I'm sure the users would appreciate if we have
the DOCOWNERS as well for various sections of the documentation : )
Shubham
On 2025-02-08, 9:
I also agree with the idea that we should go for a name that's more accurate
and easier to understand. Also, +1 to starting with Airflow 3.
Tbh "heartbeat" itself is an overused term/concept in Airflow. I think we
already have 6 configurations with "heartbeat" in it, and they're different
types
+1
We should also consider extending this abstraction to Airflow publishing (such
as notifier use cases). Haven't thought deeply about it, but the current design
only includes a consumer hook without a producer hook, suggesting an
opportunity to simplify the publishing side as well.
Thanks
Sh
20 matches
Mail list logo
