I formally cancel this vote as I am going to resume discussion on AIP-67 in the light of Airflow 3 discussions.
On Thu, May 9, 2024 at 10:40 AM Amogh Desai <amoghdesai....@gmail.com> wrote: > > 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 <ja...@potiuk.com> 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 <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? > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@airflow.apache.org For additional commands, e-mail: dev-h...@airflow.apache.org
