I agree with whatever decision comes out of this conversation going forward.
I personally think the below option is the best given the fact that we might be doing Airflow 3 with a certain theme in mind: *only implement multi-team as an Airflow 3 feature (which might be mucheasier to do - depending on the scope of Airflow 3 changes we will target -some of the changes proposed have a significant overlap with the multi-teamproposal and we should make sure to discuss it as part of our Airflow 3planning.* Thanks & Regards, Amogh Desai On Thu, May 9, 2024 at 1:35 PM Jarek Potiuk <[email protected]> wrote: > Just to clarify the state for that one. > > I would like to put that one on-hold until we get clarity on Airflow 2 vs > Airflow 3 approach: > https://lists.apache.org/thread/3chvg9964zvh15mtrbl073f4oj3nlzp2 > > There is currently a veto from Ash, so until it is withdrawn or we change > the problematic "team" database schema modification approach. I think > the choice we made here depends a lot on the Airflow 3 discussions. > > We have those options here: > > * Treat Airflow 2 multi-team approach as a "tactical" solution and > implement it in a non-future compliant way (and make use of the Airflow 3 > feature to implement it better for Airflow 3). This one is simplest and has > very limited impact on UI/API/DB etc. (so basically ripple effect) > * Implement Multi-team as Future-proof in Airflow 2 with proper schema > changes and ripple effects it might have for the UI, API and all the other > components > * only implement multi-team as an Airflow 3 feature (which might be much > easier to do - depending on the scope of Airflow 3 changes we will target - > some of the changes proposed have a significant overlap with the multi-team > proposal and we should make sure to discuss it as part of our Airflow 3 > planning. > > I currently do not know which option is best - as a lot depends on Airflow > 3 discussions. So I think putting this on hold and deciding what to do > after we have more clarity is the best approach. > > J. > > > > > On Wed, Apr 24, 2024 at 9:06 PM Mehta, Shubham <[email protected]> > wrote: > > > +1 (non-binding). Looking forward to this one. > > > > Shubham > > > > On 2024-04-22, 12:31 AM, "Amogh Desai" <[email protected] > <mailto: > > [email protected]>> 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. > > > > > > > > > > > > > > AVERTISSEMENT: Ce courrier électronique provient d’un expéditeur externe. > > Ne cliquez sur aucun lien et n’ouvrez aucune pièce jointe si vous ne > pouvez > > pas confirmer l’identité de l’expéditeur et si vous n’êtes pas certain > que > > le contenu ne présente aucun risque. > > > > > > > > > > > > > > +1 binding. > > > > > > Excited to see this happen! > > > > > > Thanks & Regards, > > Amogh Desai > > > > > > > > > > On Sat, Apr 20, 2024 at 12:11 AM Igor Kholopov <[email protected] > > <mailto:[email protected]>lid> > > wrote: > > > > > > > +1 (non-binding) > > > > > > Great to see this happening, hope we will see more proposals towards > > making > > > Airflow more flexible! > > > > > > Regards, > > > Igor > > > > > > On Fri, Apr 19, 2024 at 8:10 PM Daniel Standish > > > <[email protected] <mailto: > > [email protected]>lid> wrote: > > > > > > > > > > > > > It doesn’t affect my vote on the API, but I am very strongly > against > > > this > > > > > one part of the AIP: > > > > > > … dag_id are namespaced with `<team>:` prefix. > > > > > This specific part is getting an implementation/code veto from me. > We > > > > made > > > > > the mistake of overloading one column to store multiple things in > > > Airflow > > > > > before, and I’ve dealt with the fallout in other apps in the past. > > > Trust > > > > > me: do. not. do. this. > > > > > > > > I agree with Ash's sentiment. Is adding a tenant_id or something so > > > > unpalatable? > > > > > > > > > > > > > > > >
