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 <shu...@amazon.com.invalid> wrote: > +1 (non-binding). Looking forward to this one. > > Shubham > > On 2024-04-22, 12:31 AM, "Amogh Desai" <amoghdesai....@gmail.com <mailto: > amoghdesai....@gmail.com>> 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 <ikholo...@google.com.inva > <mailto:ikholo...@google.com.inva>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 > > <daniel.stand...@astronomer.io.inva <mailto: > daniel.stand...@astronomer.io.inva>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? > > > > > > > > >
