Hi,
I'd favor to make it usable - especially as we are at 80%.
Main motivation is that with our environment we see stability problems with the
distributed setup and using Celery, which was the main motivation to spin the
discussion about AIP-69. AIP-69 is depending on the feature. Waiting anoth
+1 binding
Mit freundlichen Grüßen / Best regards
Jens Scheffler
Alliance: Enabler - Tech Lead (XC-AS/EAE-ADA-T)
Robert Bosch GmbH | Hessbruehlstraße 21 | 70565 Stuttgart-Vaihingen | GERMANY |
www.bosch.com
Tel. +49 711 811-91508 | Mobil +49 160 90417410 | jens.scheff...@de.bosch.com
Sitz: Stu
It feels a little weird to add a new "forever" experimental feature in
Airflow 2 that we already know won't be there in Airflow 3. Not something
I'd want to be really user facing at this point in time either.
Given the short timeline for Airflow 3, I imagine we'd be better off
spending those cycle
I would favor moving towards Airflow 3 and delivering a fully-baked feature.
On Thu, 11 Jul 2024 at 18:28, Jarek Potiuk wrote:
> Following up after today's Airflow 3 call, I wanted to start
> discussion on whether we should continue implementing AIP-44 and
> release it in Airflow 2 or whether we
Following up after today's Airflow 3 call, I wanted to start
discussion on whether we should continue implementing AIP-44 and
release it in Airflow 2 or whether we should focus on AIP-72 and
Airflow 3.
We could go both ways.
The implementation is somewhat 80% done - what we really miss there is
a
+1 binding
As Jarek mentioned, still some discussions ongoing but I think that can be
hashed out later. Looks good overall.
From: Elad Kalif
Sent: Thursday, July 11, 2024 9:11:19 AM
To: dev@airflow.apache.org
Subject: RE: [EXT] [VOTE] AIP-72: Task Execution Inte
+1 binding
On Thu, Jul 11, 2024 at 5:50 PM Bishundeo, Rajeshwar
wrote:
> +1 non-binding
>
> -- Rajesh
>
>
>
>
>
>
> On 2024-07-11, 9:57 AM, "Vincent Beck" vincb...@apache.org>> wrote:
>
>
> CAUTION: This email originated from outside of the organization. Do not
> click links or open attachment
+1 non-binding
-- Rajesh
On 2024-07-11, 9:57 AM, "Vincent Beck" mailto:vincb...@apache.org>> wrote:
CAUTION: This email originated from outside of the organization. Do not click
links or open attachments unless you can confirm the sender and know the
content is safe.
AVERTISSEMEN
+1 binding
On Thu, Jul 11, 2024 at 6:58 AM Vincent Beck wrote:
> +1 binding
>
> On 2024/07/11 13:32:14 Igor Kholopov wrote:
> > +1, non-binding
> >
> > Some alignment with AIP-66 might be required, but the general vision
> > implementation looks clear to me.
> >
> > Thanks for leading this eff
+1 binding
On 2024/07/11 13:32:14 Igor Kholopov wrote:
> +1, non-binding
>
> Some alignment with AIP-66 might be required, but the general vision
> implementation looks clear to me.
>
> Thanks for leading this effort!
>
> On Thu, Jul 11, 2024 at 3:21 PM Jed Cunningham
> wrote:
>
> > +1 bindin
+1, non-binding
Some alignment with AIP-66 might be required, but the general vision
implementation looks clear to me.
Thanks for leading this effort!
On Thu, Jul 11, 2024 at 3:21 PM Jed Cunningham
wrote:
> +1 binding
>
+1 binding
+1 binding
On Thu, Jul 11, 2024 at 6:06 PM Buğra Öztürk
wrote:
> +1 non-binding
>
> On Thu, 11 Jul 2024, 14:21 Maciej Obuchowski,
> wrote:
>
> > +1 binding.
> >
> > czw., 11 lip 2024 o 14:15 Kaxil Naik napisał(a):
> >
> > > +1 binding
> > >
> > > On Thu, 11 Jul 2024 at 12:39, Jarek Potiuk wro
+1 non-binding
On Thu, 11 Jul 2024, 14:21 Maciej Obuchowski,
wrote:
> +1 binding.
>
> czw., 11 lip 2024 o 14:15 Kaxil Naik napisał(a):
>
> > +1 binding
> >
> > On Thu, 11 Jul 2024 at 12:39, Jarek Potiuk wrote:
> >
> > > I am +1 on it.
> > >
> > > While there are still open discussions on detai
+1 binding.
czw., 11 lip 2024 o 14:15 Kaxil Naik napisał(a):
> +1 binding
>
> On Thu, 11 Jul 2024 at 12:39, Jarek Potiuk wrote:
>
> > I am +1 on it.
> >
> > While there are still open discussions on details there, I think the
> > overall general direction is hashed out "good enough". Certainly
+1 binding
On Thu, 11 Jul 2024 at 12:39, Jarek Potiuk wrote:
> I am +1 on it.
>
> While there are still open discussions on details there, I think the
> overall general direction is hashed out "good enough". Certainly in
> the "what we want to achieve" and "what limitations it will bring" but
>
I am +1 on it.
While there are still open discussions on details there, I think the
overall general direction is hashed out "good enough". Certainly in
the "what we want to achieve" and "what limitations it will bring" but
also "what interaction it will have with other AIPs" and we do not
have to
I’m calling for a vote on this AIP
https://cwiki.apache.org/confluence/display/AIRFLOW/AIP-72+Task+Execution+Interface+aka+Task+SDK
Previous discussion thread was
https://lists.apache.org/thread/drfmwbx5brtycjkmtf51owrmhvmlx2lk
Based on the recent discussions I have added the section titled "Dag
+1 (non-binding) ran a few examples of dags and they worked as expected.
Thanks,
Utkarsh Sharma
On Thu, Jul 11, 2024 at 1:09 PM Freddy Demiane
wrote:
> +1 (non-binding) for Google Provider Package. We ran our system tests CI
> against providers-google/10.21.0rc1 and we got green tests.
>
> On
Yes. I think we all agree this should be a truly exceptional case with
wide impact and one that has no easy workaround (an example of such
issues from the past were when we have not realized that an older
version of ads-sdk has been disabled and none of the previous
providers would work. Or when th
+1 (non-binding) for Google Provider Package. We ran our system tests CI
against providers-google/10.21.0rc1 and we got green tests.
On Wed, Jul 10, 2024 at 5:54 PM Vincent Beck wrote:
> -1 for amazon provider package because of
> https://github.com/apache/airflow/pull/40690
>
> On 2024/07/10 03
21 matches
Mail list logo
