Re: [VOTE] Airflow Providers prepared on April 10, 2025

+1 non binding for apache-airflow-providers-amazon==9.6.0rc1. All AWS system tests are passing against apache-airflow-providers-amazon==9.6.0rc1. You can see the results here: https://aws-mwaa.github.io/#/open-source/system-tests/version/6bd535471819074f74b0c3a3251a823be24c61b0_9.6.0rc1.html.

Re: [DISCUSS] Minimum versions of providers for Airflow 3

I assume this is not necessary when the constraint is already set on the provider side? For example, FAB provider has a dependency on Airflow 3 (`apache-airflow>=3.0.0` in `providers/fab/pyproject.toml`) On 2025/04/10 17:22:13 Jarek Potiuk wrote: > Hello, > > TL;DR; Do people who work on some p

Re: [DISCUSS] confusing alert re SimpleAuthManager

fo block, with > > details and mention of other Auth Manager in case more use cases need to be > > supported. (Or link to doc etc) > > > > Also we can easily add a “don’t show again” box or something like that, > > stored on the client side and remove the message if

Re: [ANNOUNCEMENT] airflow-core is there (finally!)

It has never been simpler to contribute to Airflow! Awesome job Jarek :) On 2025/03/21 13:50:05 Jarek Potiuk wrote: > Quick additional info - if you have in your repo a 'tests` or 'airflow' > folder remaining in the root of the repo - because you had some extra files > in those (for example genera

Re: New committer: Rahul Vats

Congrats Rahul! Very well deserved! On 2025/03/31 19:08:09 Shubham Raj wrote: > Congrats Rahul, well deserved!! > > On Tue, 1 Apr 2025 at 00:33, Vishnu Chilukoori > wrote: > > > Congrats Rahul...well deserved!! > > > > > > -- > > Regards, > > Vishnu Chilukoori > > > > On Mon, Mar 31, 2025 at 11

Re: [ANNOUNCE] UV mandatory tooling and (much nicer) doc building coming

Another huge PR for another massive change. Thanks for the effort Jarek! On 2025/04/03 10:05:50 Kunal Bhattacharya wrote: > Thank you so much for this Jarek, incredible effort. uv really has been a > lifesaver and I can't wait to now try out the simplified dev workflow. > > Regards, > Kunal Bhatt

Re: [DISCUSS] confusing alert re SimpleAuthManager

he logs into a low-grade production SAM by the fact > of configure users/password in a secure way. > > Now, the question is what it mean for the confugurationto to be 'secure'. > > J > > > czw., 27 mar 2025, 19:56 użytkownik Vincent Beck > napisał: > > &g

Re: [DISCUSS] confusing alert re SimpleAuthManager

is also a problem; username is > viewable as plain text in the UI and things like password managers. > > > > On 28 Mar 2025, at 02:56, Vincent Beck wrote: > > > > Is the security issue only printing out the passwords in stdout? If yes, I > > can easily remove t

Re: [DISCUSS] confusing alert re SimpleAuthManager

ik wrote: > > > > > >> message cut: > > >> > > >> I am fine with Option (1) given the current time constraints and since > > it > > >> is for dev only and can be iterated in follow-up releases > > >> > > >> > >

Re: [DISCUSS] confusing alert re SimpleAuthManager

does not have. And KeyCloack is a > decent option for this! > > ________ > From: Vincent Beck > Sent: Monday, March 24, 2025 6:04:42 AM > To: dev@airflow.apache.org > Subject: RE: [EXT] [DISCUSS] confusing alert re SimpleAuthManager > > CAUT

Re: [ANNOUNCEMENT] airflow-core is there (finally!)

; > > > > > > > > > Cool > > > > > > > > > > > > On Fri, 21 Mar 2025 at 20:46, Aritra Basu < > > aritrabasu1...@gmail.com> > > > > > > wrote: > > > > > > > > > > > > >

Re: [VOTE] March 2025 PR of the Month

My vote goes for https://github.com/apache/airflow/pull/47432. That was a major security issue with the way the JWT token was exchanged and it got it fixed after multiple iterations. But to be honest, there are at least 5 other PRs I'd also like to nominate, it has been a good month :) On 2025

Re: [DISCUSS] confusing alert re SimpleAuthManager

ng an application to always be secure by default, > we can focus on maintaining integration within SAM. > > On Fri, Mar 21, 2025 at 7:28 PM Vincent Beck wrote: > > > We could simply stop printing out these passwords. Passwords are auto > > generated

Re: [DISCUSS] confusing alert re SimpleAuthManager

This alert can be definitely improved. I do think we should have it and we should not remove it. If you have some proposals, please feel free to create a PR, I'll be happy to review. Mentioning the other auth managers as alternatives is, I think, a great idea. On 2025/03/21 07:20:26 Amogh Desai

Re: [DISCUSSION] Move Git DAG Bundle to Providers

+1. Makes total sense to me On 2025/03/14 06:38:29 Wei Lee wrote: > +1 sounds like a good idea! > > Best, > Wei > > > On Mar 14, 2025, at 1:47 PM, Amogh Desai wrote: > > > > Good idea, +1 for that idea to be able to decouple it out of core > > > > Thanks & Regards, > > Amogh Desai > > > > >

Re: New committers: Shubham Raj, Buğra Öztürk, LIU ZHE YOU, Kalyan Reddy !

Congrats everyone, well deserved! A lot of hard work! On 2025/03/14 12:48:46 Hemkumar Chheda wrote: > Fantastic News! Congratulations Everyone 🎉 > > Regards, > Hemkumar > > > On 14 Mar 2025, at 6:11 PM, Ankit Chaurasia wrote: > > > > Congrats everyone. > > > > *Ankit Chaurasia* > > > > > >

Re: [DISCUSS] Auth backends

documentation informing users that this approach is experimental/temporary and may change in the future. What do you think? On 2025/03/03 17:51:45 Vincent Beck wrote: > Yes, 100%. > > On 2025/03/03 17:33:55 Ash Berlin-Taylor wrote: > > So is the auth manager involved in interpreting the

Re: [DISCUSS] Turn "tests_common" into separate distribution for development

devel-common makes sense to me On 2025/03/04 21:13:47 "Oliveira, Niko" wrote: > +1 to devel-common from me > > > From: Ferruzzi, Dennis > Sent: Tuesday, March 4, 2025 11:21:20 AM > To: dev@airflow.apache.org > Subject: RE: [EXT] [DISCUSS] Turn "tests_common" into

Re: [DISCUSS] Auth backends

Yes, 100%. On 2025/03/03 17:33:55 Ash Berlin-Taylor wrote: > So is the auth manager involved in interpreting the JWT token in to something > more meaningful in order to make permission decisions etc then? > > > On 3 Mar 2025, at 16:38, Vincent Beck wrote: > > > > JW

Re: [DISCUSS] Auth backends

Hi Ash, Sure, let me try to give more details. > Can you give a concrete example of the request flow between browser/CLI, the > API server and any backends? Assuming FAB auth manager is configured in the environement. Here is the API call to create a JWT token: ``` curl -X 'POST' \ 'http://

Re: 📢 Apache Airflow 3.0.0beta1 is available for testing! 🎉

Amazing! On 2025/02/28 09:07:49 Aritra Basu wrote: > Great job all! Love seeing 3.0 taking shape! > -- > Regards, > Aritra Basu > > On Fri, 28 Feb 2025, 2:01 pm Jarek Potiuk, wrote: > > > Awesome! > > > > On Fri, Feb 28, 2025 at 7:47 AM Amogh Desai > > wrote: > > > > > Thank you Jed for gettin

Re: Two Hard Things: Deadline Alerts Edition

+1 for reference, it reads well and makes sense to me On 2025/02/24 18:15:02 Tzu-ping Chung wrote: > I like StartsFrom, but “DeadlineStartsFrom” sounds like when the deadline is. > It should have another word in front. > > DeadlineReference sounds reasonable to me. Something like DeadlineBase or

Re: [DISCUSS] Time to say goodbye to the old UI?

HUGE +1! That would have multiple benefits: - Forcing people to use the new UI will help us to identity bugs/gaps in the new UI - There is still quite a bit of code in Airflow codebase (especially in auth managers) to support old UI. Removing the old UI would allow us to clean that up On 2025/02

Re: [DISCUSS] Turn "tests_common" into separate distribution for development

Overall +1 on this one. Regarding the naming, why not keeping "tests_common" instead of "common_test_code"? I am not a big fan of "common_test_code" but it is obviously just a personal opinion (as it is always with naming :)) On 2025/02/16 13:30:09 Jarek Potiuk wrote: > > Just wondernig... would

Re: [DISCUSS]: Proposing a "common message queue" abstraction

o be a simple abstraction > over Apache Kafka, Amazon SQS, Google PubSub, and others messaging > frameworks. > > > One of the key initial goals is to provide a simple DAG writing abstraction > for integrating Event Driven Scheduling coming with Airflow 3 with > streaming system

Re: [DISCUSS] Better CODEOWNERS - reflecting actual "interest" and "committment" in certain areas

+1 on that proposal, refreshing the code owners would be a great idea. That is something that could help to reduce the number of stale PRs. On 2025/02/09 07:17:56 Amogh Desai wrote: > Love this idea! > > Yeah, I felt that CODEOWNERS file was a little bit outdated in the context > of Airflow 3 >

Re: [LAZY CONSENSUS] AIP-82 - Create new interface `BaseEventTrigger`

Consensus has been reached. You can see the change here: https://github.com/apache/airflow/pull/46391 Thanks. On 2025/01/31 00:09:15 Vikram Koka wrote: > Vincent, > > Thank you for taking the feedback and the quick update. > > Vikram > > On 2025/01/29 19:12:17 "Beck, Vincent" wrote: > > Hel

Re: 📢 Apache Airflow 3.0.0apha1 is available for testing! 🎉

Huge milestone!! Good job everyone for the hard work!! On 2025/02/02 08:03:54 Rahul Vats wrote: > This is great news! Thanks, everyone, for your outstanding efforts in > getting our first alpha release out for testing. > > We have a test plan available here >

Re: [VOTE] January 2024 PR of the Month

+1 for #45563 (Sphinx). A very good first step forward! On 2025/01/28 08:34:31 Jarek Potiuk wrote: > Yeah, I am also for Sphinx #45563. > > I think we have plenty of "new feature" PRs that a lot of busy folks are > working on so this is really a tough one, but I think those PR will be > praised a

Re: [DISCUSS] Drop support for the DAG processor embedded in the scheduler

+1 On 2025/01/10 15:50:55 Igor Kholopov wrote: > The only thing that we need to clear out before this is sealed - what are > we going to do with SQLite? SQLite supports concurrent connections if the > processes are on the same host and we already have WAL enabled by Ash in > https://github.com/apa

Re: [ANNOUNCEMENT] Moving Providers to separate sub-projects soon-ish

; > >>>> > > > >>>>> On 7 Jan 2025, at 18:33, Jarek Potiuk wrote: > > > >>>>> > > > >>>>> I think it will be better to keep it. > > > >>>>> > > > >>>>> The reason

Re: [ANNOUNCEMENT] Moving Providers to separate sub-projects soon-ish

Good question. I always found it confusing to have some providers at different level. Examples: - "airbyte" in "providers" directory (I would qualify it as "regular" provider) - "hive" in "providers/apache" - "amazon" in "providers" but which contains only one sub directory "aws" I would be in fa

Re: [ANNOUNCE] Simplified (and safer) CI workflows !

Wow! Massive change! Thanks to all who contributed :) On 2025/01/06 08:05:20 Ephraim Anierobi wrote: > Awesome work! Thank you, Jarek and Pavan! > > - Ephraim > > On Sat, 4 Jan 2025 at 13:45, Shahar Epstein wrote: > > > Well done Jarek and Pavan! > > > > Shahar > > > > On Mon, Dec 30, 2024 at

Re: AIP-84 Public API Migration

HUGE! On 2024/11/28 17:25:45 Jarek Potiuk wrote: > WOOWOOWOW! > > On Thu, Nov 28, 2024 at 6:11 PM Pierre Jeambrun > wrote: > > > Hello all, > > > > We just completed the migration of the public API to the new FastAPI > > server, closing a big one https://github.com/apache/airflow/issues/423

Re: Adding a significant newsfragment template to ease breaking change tracking

Very nice indeed :) On 2024/11/27 14:46:28 Kaxil Naik wrote: > Nice, a good step for categorization for breaking changes. > > On Wed, 27 Nov 2024 at 13:38, Amogh Desai wrote: > > > Nice! > > > > It was really hard to do back and forth with the precommit while adding a > > significant > > one. T

Re: [Discuss] Airflow 2 to 3 migration rules

g, according to > https://github.com/apache/airflow/issues/41641#issuecomment-2485622598) > > Best, > Wei > > [1] https://lists.apache.org/thread/zzvhglssmljlfdypp3c7kj8c53f6nvdv > > > On Nov 21, 2024, at 9:00 PM, Vincent Beck wrote: > > > > Hi Wei, &

Re: [Discuss] Airflow 2 to 3 migration rules

Hi Wei, Thanks for doing it. Pretty impressive the number of changes we did :) Just one clarification though (and sorry if it was mentioned somewhere else), what do you exactly mean by "If everything looks good, please click the checkbox in". Do you mean if the change listed is indeed a breakin

Re: [VOTE] Airflow Providers prepared on November 14, 2024

+1 non binding. All AWS system tests are running successfully using apache-airflow-providers-amazon==9.1.0rc4. Only example_comprehend_document_classifier is failing but is already failing in main (AWS team is working on a fix). You can see the results here: https://aws-mwaa.github.io/#/open-so

Re: [LAZY CONSENSUS] Create major version of FAB provider compatible only with Airflow 3

Lazy consensus has passed. Preparation of Fab provider to set next version as major version here: https://github.com/apache/airflow/pull/43939 On 2024/11/07 00:08:14 Jarek Potiuk wrote: > Yeah. That's the best course of action, I think ... > > On Wed, Nov 6, 2024 at 6:55 PM Beck, Vincent > wrot

Re: [VOTE] AIP-86 Deadline Alerts (Formerly SLAs)

+1 binding On 2024/11/05 17:57:44 Vikram Koka wrote: > +1 binding > Good job working through all the details and all the feedback. > > Looking forward to this! > > Vikram > > > On Tue, Nov 5, 2024 at 9:46 AM Bishundeo, Rajeshwar > wrote: > > > +1 non-binding. Exciting!! > > > > -- Rajesh > >

Re: [VOTE] Airflow Providers prepared on September 21, 2024

+1 non binding. All AWS system tests ran successfully against apache-airflow-providers-amazon==8.29.0rc1. You can see the dashboard here: https://aws-mwaa.github.io/#/open-source/system-tests/version/e1085c4b258823d86a738c5364997196d9086fef_8.29.0rc1.html On 2024/09/23 12:46:46 Vishnu Chilukoori

Re: [LAZY CONSENSUS] "Edge" as the name for AIP-69

On one side it makes sense to me, and I actually like the thinking "providers should only be for DAG authors". That makes it simple to figure whether something should belong to providers. If we go that way then FAB would no longer be a provider but a plugin which would be one step closer to not

Re: [VOTE] Airflow 2.11 as bridge release

+1 binding On 2024/09/05 11:46:35 Pierre Jeambrun wrote: > +1 (binding) > > On Thu, Sep 5, 2024 at 12:36 PM Utkarsh Sharma > wrote: > > > + 1 Non-binding > > > > Thanks, > > Utkarsh Sharma > > > > On Thu, Sep 5, 2024 at 3:06 PM Eugen Kosteev wrote: > > > > > +1 (non-binding) > > > > > > On Thu

Re: [DISCUSS] Name for the Executor of AIP-69

Distributed makes more sense to me. +1 binding on this one. Remote executor is too broad to me On 2024/08/27 14:43:33 Jarek Potiuk wrote: > I prefer distributed - as Remote executor is already a well-established > term. But this is -0.5 on "remote" - if others think it's ok, I am fine. > > On Tu

Re: [VOTE] Airflow Providers prepared on August 19, 2024

+1 non binding. All AWS system tests are running successfully against apache-airflow-providers-amazon==8.28.0rc1. You can see the results here: https://aws-mwaa.github.io/#/open-source/system-tests/version/8def71479a8a4e943f8c39f07793c9fb2cf1fcc6_8.28.0rc1.html On 2024/08/19 11:06:07 Jarek Potiu

Re: [VOTE] New Provider for Core operators/sensor

Same here, +1 essential/essentials -1 under common Binding On 2024/08/19 13:38:38 Pavankumar Gopidesu wrote: > Yes, I agree with Jarek :) > > +1 essential or essentials > -1 under common > (non-binding) > > Regards, > Pavan > > On Mon, Aug 19, 2024 at 2:32 PM Jarek Potiuk wrote: > > > +1 es

Re: [DISCUSS] New provider Common.time

I like that idea too! +1. The name does not bother me either, "common" can refer to "common use cases" or "common usage" which makes sense (at least to me). On 2024/08/14 13:23:26 Elad Kalif wrote: > Thanks for owning it Rom! > +1 from me > > The common is needed because we have convention wher

Re: [VOTE] AIP-81 Enhanced Security in CLI via Integration of API

+1 binding On 2024/08/12 13:32:09 Wei Lee wrote: > +1 binding. > > Best, > Wei > > > On Aug 12, 2024, at 9:58 AM, Kaxil Naik wrote: > > > > +1 binding > > > > On Sun, 11 Aug 2024 at 19:30, Jarek Potiuk wrote: > > > >> +1 (binding) - there are likely some small details to work out during the

Re: [VOTE] Airflow Providers prepared on August 03, 2024

+1 non binding. All AWS system tests are running successfully against apache-airflow-providers-amazon==8.27.0rc2. You can see the results here: https://aws-mwaa.github.io/#/open-source/system-tests/version/1544b08523cfe9f3048cc5e8eb1b995f3bb81120_8.27.0rc2.html On 2024/08/06 10:08:04 Pankaj Sing

Re: [ANNOUNCE] New PMC member: Jens Schaffler

Congrats Jens!! On 2024/08/06 14:31:03 Wei Lee wrote: > Congrats Jens! 🎉 > > Best, > Wei > > > On Aug 6, 2024, at 10:20 PM, Ash Berlin-Taylor wrote: > > > > Well deserved! > > > > On 6 August 2024 13:12:28 BST, Pankaj Singh > > wrote: > >> Congrats Jens 🎉 > >> > >> On Tue, Aug 6, 2024 at 4

Re: [VOTE] AIP-67 - Multi-team deplyment of Airflow Components

+1 binding. Very good demonstration of perseverance on this one :) On 2024/08/02 20:02:00 "Bishundeo, Rajeshwar" wrote: > +1 non-binding. > > Great job to all the folks getting this feature 1-step closer to reality! > > -- Rajesh > > > > > > > On 2024-08-02, 3:57 PM, "Mehta, Shubham"

Re: [DISCUSS] External event driven scheduling in Airflow

OTE to get started on this one. I think most of > > the > > > > > > commenters and those who replied to this email are happy with the > > > > > proposal > > > > > > on the poll-based approach. > > > > > > >

Re: [VOTE] AIP-79 & AIP-84 Remove Flask AppBuilder as a Core Dependency & UI REST API

Big +1 to this one. I think this is the major blocker on that workstream: deciding which tool we want to leverage to build the default auth manager for Airflow 3. Once that decision taken I'll be happy to help to implement the auth manager based upon that tool. On 2024/08/02 16:06:00 Jarek Pot

Re: [VOTE] AIP-79 & AIP-84 Remove Flask AppBuilder as a Core Dependency & UI REST API

+1 binding for both On 2024/08/01 18:33:51 Jed Cunningham wrote: > +1 binding! > - To unsubscribe, e-mail: dev-unsubscr...@airflow.apache.org For additional commands, e-mail: dev-h...@airflow.apache.org

Re: [DISCUSS] External event driven scheduling in Airflow

poll-based approach -- left a comment on the push-based: I am not sure of > > why we need a function since create asset event API endpoint should have > > all info needed for what the Asset was. > > > > On Thu, 1 Aug 2024 at 01:14, Kaxil Naik wrote: > > > > >

Re: [VOTE] AIP-83 Remove Execution Date Unique Constraint from DAG Run

+1 binding On 2024/08/01 14:05:35 Brent Bovenzi wrote: > +1 (binding) > > On Thu, Aug 1, 2024 at 2:12 AM Tzu-ping Chung > wrote: > > > Oops, forgot to attach an end date /facepalm > > > > Let’s do the minimum since there seems to be not much concerns behind this. > > > > The vote will run until

Re: [DISCUSS] External event driven scheduling in Airflow

/confluence/display/AIRFLOW/AIP-82+External+event+driven+scheduling+in+Airflow Vincent On 2024/07/29 15:58:23 Vincent Beck wrote: > Thanks a lot all for the comments, this is very much appreciated! I received > many comments from this thread and in confluence, thanks again. I'll try to

Re: [DISCUSS] External event driven scheduling in Airflow

Thanks a lot all for the comments, this is very much appreciated! I received many comments from this thread and in confluence, thanks again. I'll try to address them all in the AIP and will send an email in this thread once done. I will most likely revisit the push-based approach given the numbe

Re: [VOTE] AIP-68 Extended Plugin Interface for React Views

+1 binding. Very cool and needed feature allowing users to customize React views in Airflow! On 2024/07/26 16:01:21 "Scheffler Jens (XC-AS/EAE-ADA-T)" wrote: > Hi, > > Brent and me have revised the AIP-68 based on the other Airflow 3.x > discussions we had and as no further discussions are open

Re: [VOTE] AIP-78 Scheduler-managed backfills

I am all in for simplification! +1 binding On 2024/07/25 12:16:19 Igor Kholopov wrote: > +1 (non-binding) > > On Thu, Jul 25, 2024 at 2:05 PM Jarek Potiuk wrote: > > > +1 (binding) - while this one has some implications on scheduler- which I > > think are important enough to hash out and design

Re: [VOTE] AIP-65: Improve DAG history in UI

+1 binding On 2024/07/22 09:17:15 Amogh Desai wrote: > +1 binding > > Glad to see this happening > > Thanks & Regards, > Amogh Desai > > > On Sat, Jul 20, 2024 at 9:59 PM Aritra Basu > wrote: > > > +1 non-binding > > -- > > Regards, > > Aritra Basu > > > > On Sat, Jul 20, 2024, 8:03 PM Jarek

Re: [VOTE] AIP-66: DAG Bundles and Parsing

+1 binding On 2024/07/22 11:23:16 Utkarsh Sharma wrote: > +1 binding > > Thanks, > Utkarsh Sharma > > On Mon, Jul 22, 2024 at 3:33 PM Amogh Desai > wrote: > > > +1 binding > > > > I really love the way the AIP has been written to target small pieces > > instead > > of doing everything related

Re: Operator Templating in Airflow 3

+1 here as well. Keeping these template_fields in sync with the parameters has always been a challenge. Happy to no longer check that when doing PR reviews. On 2024/07/18 20:14:13 "Scheffler Jens (XC-AS/EAE-ADA-T)" wrote: > Bis +1 from me. The existing Jinja Syntax was a pitfall for all firdt tim

Re: [ANNOUNCE] New committers: Rom Sharon & Shahar Epstein

Congrats!! On 2024/07/15 14:53:14 Buğra Öztürk wrote: > Congrats ! 🎉 > > On Mon, 15 Jul 2024, 16:49 Poorvi Rohidekar, > wrote: > > > Congratulations! 🎉 > > > > On Mon, 15 Jul 2024 at 19:04, Bishundeo, Rajeshwar > > wrote: > > > > > Congratulations Rom & Sharan!!! > > > > > > -- Rajesh > > > >

Re: [VOTE] Airflow Providers prepared on July 12, 2024

+1 non binding. All AWS system tests are running successfully against apache-airflow-providers-amazon==8.26.0rc2. You can see the results here: https://aws-mwaa.github.io/#/open-source/system-tests/version/a89514ec38d368efa9733c8376953024c8da9f1a_8.26.0rc2.html On 2024/07/12 14:21:54 Elad Kalif

Re: [VOTE] AIP-72: Task Execution Interface aka Task SDK

+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

Re: [VOTE] Airflow Providers prepared on July 09, 2024

ed, Jul 10, 2024 at 7:22 AM Wei Lee wrote: > > > +1 for providers other than weaviate. Ran our example DAGs and worked fine. > > > > Best, > > Wei > > > > > > > On Jul 10, 2024, at 6:42 AM, Vincent Beck wrote: > > > > > > +1 non b

Re: [VOTE] Airflow Providers prepared on July 09, 2024

+1 non binding. All AWS system tests are running successfully against apache-airflow-providers-amazon==8.26.0rc1 On 2024/07/09 15:01:36 Elad Kalif wrote: > weaviate provider is excluded from rc1 > please continue testing and voting on rest of the providers > > On Tue, Jul 9, 2024 at 4:57 PM Wei

Re: Fwd: Unsubscribe from dev@airflow.apache.org Mailing List

Please follow instructions here: https://airflow.apache.org/community/#:~:text=The%20Dev%20list%20is%20the,unsubscribe%40airflow.apache.org On 2024/07/04 20:44:42 Anum Sheraz wrote: > > > > > Dear Airflow Mailing List Admin, > > > > I hope this message finds you well. > > > > Please unsubscr

Re: [DISCUSS] @remove provide_bucket_name and @unify_bucket_name_and_key?

e get from > users... > > > > > > > > On Wed, Jul 3, 2024 at 11:25 AM Vincent Beck wrote: > > > Overall, I agree with Daniel that these decorators can be very confusing > > (as user and maintainers). > > > > - `unify_bucket_name_and_ke

Re: [DISCUSS] @remove provide_bucket_name and @unify_bucket_name_and_key?

Overall, I agree with Daniel that these decorators can be very confusing (as user and maintainers). - `unify_bucket_name_and_key`. I am +1 to remove it. To me it does not offer real value and is a just a "hack" to presumably make user life easier. I prefer having a clear API with separate param

Re: [ANNOUNCE] New committer: Ryan Hatter

Congrats!! On 2024/06/28 17:04:36 Amogh Desai wrote: > Congratulations Ryan! > > Welcome onboard :) > > Thanks & Regards, > Amogh Desai > > > On Fri, Jun 28, 2024 at 10:32 PM Jarek Potiuk wrote: > > > Congrats! > > > > On Fri, Jun 28, 2024 at 6:59 PM Jed Cunningham > > wrote: > > > > > The

Re: Using AI / Dosu to help us with triaging issues

Fantastic idea! On 2024/06/26 20:12:43 Jarek Potiuk wrote: > Hello everyone, > > Together with Elad, Kaxil, and the Dosu team [1], we’ve been looking into > employing AI / Natural Language processing to help us triage issues for > Apache Airflow. We do not want to go “all-in” into getting a chatb

RE: [VOTE] June 2024 PR of the Month

Same! +1 for #39555. Quite an impactful contribution for a first time contributor!! On 2024/06/26 20:17:47 "Scheffler Jens (XC-AS/EAE-ADA-T)" wrote: > Thanks for the proposals... > > There was a "late arrival" and month is not over... as it was a long runner > and we had a first-time contribu

Re: [VOTE] Airflow Providers prepared on June 22, 2024

+1 non binding. All AWS system tests are running successfully against apache-airflow-providers-amazon==8.25.0rc1. You can see the results here: https://aws-mwaa.github.io/#/open-source/system-tests/version/c310159bc2363c12110b11febd5febaab8670210_8.25.0rc1.html On 2024/06/24 12:43:05 Pankaj Koti

Re: Google Provider Package System Tests Dashboard

Really nice!! On 2024/06/12 11:38:13 Jarek Potiuk wrote: > > I believe we should include a reference to it in the Google provider > documentation. > > Already there: https://github.com/apache/airflow/pull/40102 in the README > documentation (which is where it should be as it is mostly > maintain

Re: [DISCUSS] indexes for API calls

Interesting thread. I think what makes this discussion complex is that Airflow makes a lot of different queries (API, Scheduler, ...). I think it is even harder to keep track of all the different queries Airflow makes and thus, hard to figure if such index is needed. Also, Airflow evolves (and

Re: [VOTE] Airflow Providers prepared on May 26, 2024

+1 non binding. All AWS system tests are running successfully against apache-airflow-providers-amazon==8.23.0rc1. You can see the results here: https://aws-mwaa.github.io/#/open-source/system-tests/version/98c5a3a2c6d1df722d56bb3748dfbc810d5952aa_8.23.0rc1.html On 2024/05/27 14:01:48 Rahul Vats

Re: [VOTE] Airflow Providers prepared on May 12, 2024

+1 non binding. All AWS system tests are running fine against apache-airflow-providers-amazon==8.22.0rc1. You can see the results here: https://aws-mwaa.github.io/#/open-source/system-tests/version/1e4663f34c2fb42b87cf75e4776650620eb2baa4_8.22.0rc1.html On 2024/05/14 08:21:12 Phani Kumar wrote:

Re: [DISCUSS] simplifying try_number handling

I am all +1 on this one. This thing gave me headaches when working on AIP-44 and I could not understand the difference between the private "_try_number" and the public "try_number". Thanks for simplifying it! This is obviously assuming it does not break anything I am not aware of :) On 2024/05/

Re: [VOTE] Airflow Providers prepared on May 01, 2024

+1 non binding. All AWS system tests are working successfully against apache-airflow-providers-amazon==8.21.0rc1. You can see the results here: https://aws-mwaa.github.io/#/open-source/system-tests/version/fe4605a10e26f1b8a180979ba5765d1cb7fb0111_8.21.0rc1.html. The only failure (example_bedrock

Re: [VOTE] AIP-67 Multi-team deployment of Airflow components

+1 binding On 2024/04/18 11:10:32 Jarek Potiuk wrote: > Hello here. > > I have not not heard a lot of feedback after my last update, so let me > start a vote, hoping that the last changes proposed addressed most of the > concerns. > > Just to recap. the proposal is here: > https://cwiki.apache.o

Re: [VOTE] Airflow Providers prepared on April 10, 2024

+1 non binding. All AWS system tests are running successfully against apache-airflow-providers-amazon==8.20.0rc1 with the exception of example_bedrock that is failing due to a bug in the test itself (fix here: https://github.com/apache/airflow/pull/38887). You can see the results here: https://

Re: [ANNOUNCE] New committer: Wei Lee

Congrats Wei! Well deserved! On 2024/04/08 13:03:50 Hemkumar Chheda wrote: > Congratulations Wei! Best news ever 🤩🥳 > > > On 8 Apr 2024, at 6:10 PM, Bishundeo, Rajeshwar > > wrote: > > > > Congratulations Wei!! Good job and well deserved!! > > > > -- Rajesh > > > > > > > > > > > > > >

Re: [DISCUSS] Applying D105 rule for our codebase ("undocumented magic methods") ?

+1 for not enforcing as well. Let's leave to maintainers the flexibility to chose whether a given method should be documented. On 2024/03/20 08:28:51 Ash Berlin-Taylor wrote: > I'm for not enforcing this rule - as others have said its very unlikely to > result in more useful docs for developers

RE: [VOTE] AIP-59 Performance testing framework

+1 (binding) On 2024/03/13 10:26:31 "Scheffler Jens (XC-AS/EAE-ADA-T)" wrote: > +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

Re: [VOTE] Release Airflow 2.8.3 from 2.8.3rc1

+1 non binding. I check my change and it works as expected. I also ran few testing DAGs and they ran fine. On 2024/03/08 00:14:12 Jarek Potiuk wrote: > +1 (binding): checked reproducibility, sources, licences, checksums, > run a few dags, tested all my changes, all looks good. > > One caveat. I

Re: [VOTE] Airflow Providers prepared on March 04, 2024

+1 non binding. All AWS system tests are running successfully against apache-airflow-providers-amazon==8.19.0rc1. You can see the results here: https://aws-mwaa.github.io/#/open-source/system-tests/version/2852976ea6321b152ebc631d30d5526703bc6590_8.19.0rc1.html On 2024/03/04 21:34:04 Elad Kalif

Re: [VOTE] Release Airflow 2.8.2 from 2.8.2rc2

+1 non binding. I ran successfully my testing DAGs. On 2024/02/23 18:14:21 Elad Kalif wrote: > +1 (binding) > checked some of my dags. Looks good > > On Fri, Feb 23, 2024 at 6:25 PM Jarek Potiuk wrote: > > > +1 (binding) > > > > * Installed and ran it locally. Ran a few DAGs, inspected the whee

Re: [VOTE] Airflow Providers prepared on February 12, 2024

+1 non binding. All AWS system tests are working fine against 8.18.0rc1. You can the results here: https://aws-mwaa.github.io/#/open-source/system-tests/version/2e1561015c44a0acfd86b63360fc17ad477a8d3b_8.18.0rc1.html On 2024/02/13 05:08:17 Wei Lee wrote: > -1 (non-binding) for amazon: 8.18.0rc1,

Re: [DISCUSS] Rename channels on slack

; > But yes, maybe we can change it to something better as well? Any > > > ideas? > > > > > > > > > > > > Why not just #first-pr > > > > > > > > > > > > Or maybe someone can propose a better name for #con

Re: [DISCUSS] Rename channels on slack

S/EAE-ADA-T) > wrote: > > > I was +1 to Jarek first but reading the counter proposal from Vicent I > > change to +1 like Vincent proposes. Also not against Jarek but shorter is > > better. > > > > Sent from Outlook for iOS<https://aka.ms/o0ukef> &

Re: [DISCUSS] Rename channels on slack

I am +1 in renaming these channels because, as said, most of messages in @development are nothing to do there. Though, I would just rename #development to #contributing. To me, #troubleshooting is already a good name and clear. But this is only my personal opinion. I am not against the names Ja

Re: [VOTE] New Airflow Community Provider: Teradata

+1 binding. Makes sense to me. On 2024/01/16 18:21:39 Jarek Potiuk wrote: > +1 binding > > On Tue, Jan 16, 2024 at 6:20 PM Phani Kumar > wrote: > > > +1 non binding > > > > On Tue, Jan 16, 2024 at 10:43 PM K Mallam, Sunil > > wrote: > > > > > Hello Airflow Community, > > > > > > Thank you very

Re: [ANNOUNCE] New PMC member: Andrey Anshin (taragolis)

Congrats Andrey! On 2024/01/15 18:46:32 ambika garg wrote: > Congrats Andrey!! > > On Mon, Jan 15, 2024 at 1:44 PM Amogh Desai > wrote: > > > Congrats Andrey!! > > > > On Tue, 16 Jan 2024 at 12:08 AM, Hussein Awala wrote: > > > > > Congratulations Andrey, very well deserved! > > > > > > On Mon

Re: [VOTE] Airflow Providers prepared on January 07, 2024

+1 non binding. All AWS system tests are running successfully against apache-airflow-providers-amazon==8.16.0rc1. You can see the results here: https://aws-mwaa.github.io/#/open-source/system-tests/version/3dc99d8a285aaadeb83797e691c9f6ec93ff9c93_8.16.0rc1.html On 2024/01/08 15:14:34 Amogh Desai

Re: [DISCUSSION] Enabling `pre-commit.ci` application for Airflow

I like the concept! +1 On 2023/12/30 11:16:35 Amogh Desai wrote: > I am aligning here with Pierre, but I am not against the idea of enabling > the pre commit ci application. > > I’d rather have myself fix the issue as it sometimes also lets me have > second,third or multiple passes at my code whi

Re: [DISCUSS] "Require conversation resolution" in our PRs before merge?

I am wondering too if this is not something that gives more work to maintainer without real benefits. A maintainer can still mark all conversations as resolved and merge the PR if he wants. Though, I understand there is the intention here as oppose as today where a maintainer can just miss some

Re: Making Listeners API non-experimental

+1 On 2023/12/15 12:51:26 Jarek Potiuk wrote: > +1. ESPECIALLY if there will be issues found that we will fix in 2.8.x :D > > On Fri, Dec 15, 2023 at 1:47 PM Elad Kalif wrote: > > > If There were no issues discovered so far I am +1 in making it non > > experimental for 2.9 > > > > On Fri, Dec 1

Re: [ANNOUNCE] New committer: Utkarsh Sharma

Congrats! On 2023/12/04 16:43:09 Jarek Potiuk wrote: > Hello everyone, > > [filling-in for Kaxil who is less available nowadays and travelling without > much access to computer] > > The Project Management Committee (PMC) for Apache Airflow > has invited Utkarsh Sharma to become a committer and w

  1   2   >