Hey Ash and Daniel (and others unconvinced), I split the discussion here so that we do not clutter the VOTE thread.
I hope I can convince you that yes, it makes sense to approach it this way and that you withdraw the veto Ash. It needs a bit of context and the separate discussion I started on Airflow 3 and Strategic vs. Tactical approach started https://lists.apache.org/thread/3chvg9964zvh15mtrbl073f4oj3nlzp2 For this particular case: I would not state it better than what Ash himself already made as the comment in the document: "I worry what this does to our database schemas! We'd need to add tennant_id to *almost every single* PK wouldn't we?" Yes. I worry about it too. And I want to avoid making huge changes to the whole Airflow with that. But also I think it should not be something we should carry forward in that form. This is mostly a "deployment" option that makes it easy to namespace and isolate DAGs - which is likely not going to be needed at all if we redesign Airflow 3 (if we go that route of course). So future-evolving approach with a complete schema etc is really not a goal here. I treat it - explicitly more as a band-aid than a long-term approach. And I think what we are really looking at with AIP-67 (like with AIP-44 - internal API and a number of others) is a tactical approach to add features that users need for Airflow 2. For me I see this AIP as a "tactical" approach, where we implement minimum things needed to support the use case for Airflow 2, but we would not want this to be carried over to what's coming next as possibly Airflow 3 - and this is why I think it's acceptable to make it a "band-aid" kind of approach. And I think we should look at this decision with that as a context. J. On Fri, Apr 19, 2024 at 8:10 PM Daniel Standish > <daniel.stand...@astronomer.io.invalid> 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? > > >
