You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@airflow.apache.org by Jarek Potiuk <ja...@potiuk.com> on 2024/04/18 11:10:32 UTC
[VOTE] AIP-67 Multi-team deployment of Airflow components
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.org/confluence/display/AIRFLOW/AIP-67+Multi-team+deployment+of+Airflow+components
Summarizing the most recent changes - responding to comments and doubts
raised during the discussion:
* renamed it to be multi-team to clarify that this is the only case it
addresses
* splitting it into two phases: without and with internal API AIP-44 (also
named as GRPC server)
* implifying the approach for Variables and Connections, where no changes
in Airflow will be needed to handle the DB updates.
This makes phase 1 simpler and not depending on AIP-44.
The vote will last till next Friday 26th of April 2024 Noon CEST.
J.
Re: [VOTE] AIP-67 Multi-team deployment of Airflow components
Posted by Amogh Desai <am...@gmail.com>.
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 <sh...@amazon.com.invalid>
> wrote:
>
> > +1 (non-binding). Looking forward to this one.
> >
> > Shubham
> >
> > On 2024-04-22, 12:31 AM, "Amogh Desai" <amoghdesai.oss@gmail.com
> <mailto:
> > amoghdesai.oss@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 <ikholopov@google.com.inva
> > <ma...@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.standish@astronomer.io.inva <mailto:
> > daniel.standish@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?
> > > >
> > >
> >
> >
> >
> >
>
Re: [VOTE] AIP-67 Multi-team deployment of Airflow components
Posted by Jarek Potiuk <ja...@potiuk.com>.
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 <sh...@amazon.com.invalid>
wrote:
> +1 (non-binding). Looking forward to this one.
>
> Shubham
>
> On 2024-04-22, 12:31 AM, "Amogh Desai" <amoghdesai.oss@gmail.com <mailto:
> amoghdesai.oss@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 <ikholopov@google.com.inva
> <ma...@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.standish@astronomer.io.inva <mailto:
> daniel.standish@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?
> > >
> >
>
>
>
>
Re: [VOTE] AIP-67 Multi-team deployment of Airflow components
Posted by "Mehta, Shubham" <sh...@amazon.com.INVALID>.
+1 (non-binding). Looking forward to this one.
Shubham
On 2024-04-22, 12:31 AM, "Amogh Desai" <amoghdesai.oss@gmail.com <ma...@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 <ikholopov@google.com.inva <ma...@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.standish@astronomer.io.inva <ma...@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?
> >
>
Re: [VOTE] AIP-67 Multi-team deployment of Airflow components
Posted by Amogh Desai <am...@gmail.com>.
+1 binding.
Excited to see this happen!
Thanks & Regards,
Amogh Desai
On Sat, Apr 20, 2024 at 12:11 AM Igor Kholopov <ik...@google.com.invalid>
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
> <da...@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?
> >
>
Team id as dag_id prefix: (was [VOTE] AIP-67)
Posted by Jarek Potiuk <ja...@potiuk.com>.
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
> <da...@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?
> >
>
Re: [VOTE] AIP-67 Multi-team deployment of Airflow components
Posted by Igor Kholopov <ik...@google.com.INVALID>.
+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
<da...@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?
>
Re: [VOTE] AIP-67 Multi-team deployment of Airflow components
Posted by Daniel Standish <da...@astronomer.io.INVALID>.
>
> 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?
Re: [VOTE] AIP-67 Multi-team deployment of Airflow components
Posted by "Hussain, Syed" <sy...@amazon.com.INVALID>.
+1 (non-binding)
Nice to see it moving along!
________________________________
From: Ash Berlin-Taylor <as...@apache.org>
Sent: Friday, April 19, 2024 9:00:42 AM
To: dev@airflow.apache.org
Subject: RE: [EXTERNAL] [COURRIEL EXTERNE] [VOTE] AIP-67 Multi-team deployment of Airflow components
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.
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.
> On 18 Apr 2024, at 12:10, Jarek Potiuk <ja...@potiuk.com> 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.org/confluence/display/AIRFLOW/AIP-67+Multi-team+deployment+of+Airflow+components
>
> Summarizing the most recent changes - responding to comments and doubts
> raised during the discussion:
>
> * renamed it to be multi-team to clarify that this is the only case it
> addresses
> * splitting it into two phases: without and with internal API AIP-44 (also
> named as GRPC server)
> * implifying the approach for Variables and Connections, where no changes
> in Airflow will be needed to handle the DB updates.
>
> This makes phase 1 simpler and not depending on AIP-44.
>
> The vote will last till next Friday 26th of April 2024 Noon CEST.
>
> J.
Re: [VOTE] AIP-67 Multi-team deployment of Airflow components
Posted by Ash Berlin-Taylor <as...@apache.org>.
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.
> On 18 Apr 2024, at 12:10, Jarek Potiuk <ja...@potiuk.com> 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.org/confluence/display/AIRFLOW/AIP-67+Multi-team+deployment+of+Airflow+components
>
> Summarizing the most recent changes - responding to comments and doubts
> raised during the discussion:
>
> * renamed it to be multi-team to clarify that this is the only case it
> addresses
> * splitting it into two phases: without and with internal API AIP-44 (also
> named as GRPC server)
> * implifying the approach for Variables and Connections, where no changes
> in Airflow will be needed to handle the DB updates.
>
> This makes phase 1 simpler and not depending on AIP-44.
>
> The vote will last till next Friday 26th of April 2024 Noon CEST.
>
> J.
Re: [VOTE] AIP-67 Multi-team deployment of Airflow components
Posted by "Scheffler Jens (XC-AS/EAE-ADA-T)" <Je...@de.bosch.com.INVALID>.
+1 binding and many thanks for the lively discussion and alignment! Get it going!
Sent from Outlook for iOS<https://aka.ms/o0ukef>
________________________________
From: Pierre Jeambrun <pi...@gmail.com>
Sent: Thursday, April 18, 2024 7:14:39 PM
To: dev@airflow.apache.org <de...@airflow.apache.org>
Subject: Re: [VOTE] AIP-67 Multi-team deployment of Airflow components
+1 (binding)
Le jeu. 18 avr. 2024 à 18:52, Ferruzzi, Dennis <fe...@amazon.com.invalid>
a écrit :
> This is exciting. +1 binding.
>
>
> - ferruzzi
>
>
> ________________________________
> From: Oliveira, Niko <on...@amazon.com.INVALID>
> Sent: Thursday, April 18, 2024 9:16 AM
> To: dev@airflow.apache.org
> Subject: RE: [EXTERNAL] [COURRIEL EXTERNE] [VOTE] AIP-67 Multi-team
> deployment of Airflow components
>
> 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 for this one!
>
> ________________________________
> From: Aritra Basu <ar...@gmail.com>
> Sent: Thursday, April 18, 2024 7:37:08 AM
> To: dev@airflow.apache.org
> Subject: RE: [EXTERNAL] [COURRIEL EXTERNE] [VOTE] AIP-67 Multi-team
> deployment of Airflow components
>
> 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 (non-binding)
>
> --
> Regards,
> Aritra Basu
>
> On Thu, Apr 18, 2024, 7:42 PM Bishundeo, Rajeshwar
> <rb...@amazon.com.invalid> wrote:
>
> > +1 (non-binding)
> >
> > -- Rajesh
> >
> >
> >
> >
> >
> >
> > On 2024-04-18, 10:11 AM, "Vincent Beck" <vincbeck@apache.org <mailto:
> > vincbeck@apache.org>> 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
> >
> >
> > 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://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FAIRFLOW%2FAIP-67%2BMulti-team%2Bdeployment%2Bof%2BAirflow%2Bcomponents&data=05%7C02%7CJens.Scheffler%40de.bosch.com%7C075ccc6635394270d26f08dc5fcb2b9d%7C0ae51e1907c84e4bbb6d648ee58410f4%7C0%7C0%7C638490573406864861%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=LEVIb6BvpfVoLciWboTSQGyWJFC1RAqIntlqYihOWrc%3D&reserved=0<https://cwiki.apache.org/confluence/display/AIRFLOW/AIP-67+Multi-team+deployment+of+Airflow+components>
> > <
> >
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FAIRFLOW%2FAIP-67%2BMulti-team%2Bdeployment%2Bof%2BAirflow%2Bcomponents&data=05%7C02%7CJens.Scheffler%40de.bosch.com%7C075ccc6635394270d26f08dc5fcb2b9d%7C0ae51e1907c84e4bbb6d648ee58410f4%7C0%7C0%7C638490573406875661%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=ImDoy%2BncJYqXOK3DA9UtfjrHFwWWIvgq6EV5sWGp5Eo%3D&reserved=0<https://cwiki.apache.org/confluence/display/AIRFLOW/AIP-67+Multi-team+deployment+of+Airflow+components>
> > >
> > >
> > > Summarizing the most recent changes - responding to comments and doubts
> > > raised during the discussion:
> > >
> > > * renamed it to be multi-team to clarify that this is the only case it
> > > addresses
> > > * splitting it into two phases: without and with internal API AIP-44
> > (also
> > > named as GRPC server)
> > > * implifying the approach for Variables and Connections, where no
> changes
> > > in Airflow will be needed to handle the DB updates.
> > >
> > > This makes phase 1 simpler and not depending on AIP-44.
> > >
> > > The vote will last till next Friday 26th of April 2024 Noon CEST.
> > >
> > > J.
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@airflow.apache.org <mailto:
> > dev-unsubscribe@airflow.apache.org>
> > For additional commands, e-mail: dev-help@airflow.apache.org <mailto:
> > dev-help@airflow.apache.org>
> >
> >
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@airflow.apache.org
> > For additional commands, e-mail: dev-help@airflow.apache.org
> >
>
Re: [VOTE] AIP-67 Multi-team deployment of Airflow components
Posted by Pierre Jeambrun <pi...@gmail.com>.
+1 (binding)
Le jeu. 18 avr. 2024 à 18:52, Ferruzzi, Dennis <fe...@amazon.com.invalid>
a écrit :
> This is exciting. +1 binding.
>
>
> - ferruzzi
>
>
> ________________________________
> From: Oliveira, Niko <on...@amazon.com.INVALID>
> Sent: Thursday, April 18, 2024 9:16 AM
> To: dev@airflow.apache.org
> Subject: RE: [EXTERNAL] [COURRIEL EXTERNE] [VOTE] AIP-67 Multi-team
> deployment of Airflow components
>
> 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 for this one!
>
> ________________________________
> From: Aritra Basu <ar...@gmail.com>
> Sent: Thursday, April 18, 2024 7:37:08 AM
> To: dev@airflow.apache.org
> Subject: RE: [EXTERNAL] [COURRIEL EXTERNE] [VOTE] AIP-67 Multi-team
> deployment of Airflow components
>
> 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 (non-binding)
>
> --
> Regards,
> Aritra Basu
>
> On Thu, Apr 18, 2024, 7:42 PM Bishundeo, Rajeshwar
> <rb...@amazon.com.invalid> wrote:
>
> > +1 (non-binding)
> >
> > -- Rajesh
> >
> >
> >
> >
> >
> >
> > On 2024-04-18, 10:11 AM, "Vincent Beck" <vincbeck@apache.org <mailto:
> > vincbeck@apache.org>> 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
> >
> >
> > 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.org/confluence/display/AIRFLOW/AIP-67+Multi-team+deployment+of+Airflow+components
> > <
> >
> https://cwiki.apache.org/confluence/display/AIRFLOW/AIP-67+Multi-team+deployment+of+Airflow+components
> > >
> > >
> > > Summarizing the most recent changes - responding to comments and doubts
> > > raised during the discussion:
> > >
> > > * renamed it to be multi-team to clarify that this is the only case it
> > > addresses
> > > * splitting it into two phases: without and with internal API AIP-44
> > (also
> > > named as GRPC server)
> > > * implifying the approach for Variables and Connections, where no
> changes
> > > in Airflow will be needed to handle the DB updates.
> > >
> > > This makes phase 1 simpler and not depending on AIP-44.
> > >
> > > The vote will last till next Friday 26th of April 2024 Noon CEST.
> > >
> > > J.
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@airflow.apache.org <mailto:
> > dev-unsubscribe@airflow.apache.org>
> > For additional commands, e-mail: dev-help@airflow.apache.org <mailto:
> > dev-help@airflow.apache.org>
> >
> >
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@airflow.apache.org
> > For additional commands, e-mail: dev-help@airflow.apache.org
> >
>
Re: [VOTE] AIP-67 Multi-team deployment of Airflow components
Posted by "Ferruzzi, Dennis" <fe...@amazon.com.INVALID>.
This is exciting. +1 binding.
- ferruzzi
________________________________
From: Oliveira, Niko <on...@amazon.com.INVALID>
Sent: Thursday, April 18, 2024 9:16 AM
To: dev@airflow.apache.org
Subject: RE: [EXTERNAL] [COURRIEL EXTERNE] [VOTE] AIP-67 Multi-team deployment of Airflow components
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 for this one!
________________________________
From: Aritra Basu <ar...@gmail.com>
Sent: Thursday, April 18, 2024 7:37:08 AM
To: dev@airflow.apache.org
Subject: RE: [EXTERNAL] [COURRIEL EXTERNE] [VOTE] AIP-67 Multi-team deployment of Airflow components
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 (non-binding)
--
Regards,
Aritra Basu
On Thu, Apr 18, 2024, 7:42 PM Bishundeo, Rajeshwar
<rb...@amazon.com.invalid> wrote:
> +1 (non-binding)
>
> -- Rajesh
>
>
>
>
>
>
> On 2024-04-18, 10:11 AM, "Vincent Beck" <vincbeck@apache.org <mailto:
> vincbeck@apache.org>> 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
>
>
> 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.org/confluence/display/AIRFLOW/AIP-67+Multi-team+deployment+of+Airflow+components
> <
> https://cwiki.apache.org/confluence/display/AIRFLOW/AIP-67+Multi-team+deployment+of+Airflow+components
> >
> >
> > Summarizing the most recent changes - responding to comments and doubts
> > raised during the discussion:
> >
> > * renamed it to be multi-team to clarify that this is the only case it
> > addresses
> > * splitting it into two phases: without and with internal API AIP-44
> (also
> > named as GRPC server)
> > * implifying the approach for Variables and Connections, where no changes
> > in Airflow will be needed to handle the DB updates.
> >
> > This makes phase 1 simpler and not depending on AIP-44.
> >
> > The vote will last till next Friday 26th of April 2024 Noon CEST.
> >
> > J.
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@airflow.apache.org <mailto:
> dev-unsubscribe@airflow.apache.org>
> For additional commands, e-mail: dev-help@airflow.apache.org <mailto:
> dev-help@airflow.apache.org>
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@airflow.apache.org
> For additional commands, e-mail: dev-help@airflow.apache.org
>
Re: [VOTE] AIP-67 Multi-team deployment of Airflow components
Posted by "Oliveira, Niko" <on...@amazon.com.INVALID>.
+1 binding
Excited for this one!
________________________________
From: Aritra Basu <ar...@gmail.com>
Sent: Thursday, April 18, 2024 7:37:08 AM
To: dev@airflow.apache.org
Subject: RE: [EXTERNAL] [COURRIEL EXTERNE] [VOTE] AIP-67 Multi-team deployment of Airflow components
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 (non-binding)
--
Regards,
Aritra Basu
On Thu, Apr 18, 2024, 7:42 PM Bishundeo, Rajeshwar
<rb...@amazon.com.invalid> wrote:
> +1 (non-binding)
>
> -- Rajesh
>
>
>
>
>
>
> On 2024-04-18, 10:11 AM, "Vincent Beck" <vincbeck@apache.org <mailto:
> vincbeck@apache.org>> 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
>
>
> 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.org/confluence/display/AIRFLOW/AIP-67+Multi-team+deployment+of+Airflow+components
> <
> https://cwiki.apache.org/confluence/display/AIRFLOW/AIP-67+Multi-team+deployment+of+Airflow+components
> >
> >
> > Summarizing the most recent changes - responding to comments and doubts
> > raised during the discussion:
> >
> > * renamed it to be multi-team to clarify that this is the only case it
> > addresses
> > * splitting it into two phases: without and with internal API AIP-44
> (also
> > named as GRPC server)
> > * implifying the approach for Variables and Connections, where no changes
> > in Airflow will be needed to handle the DB updates.
> >
> > This makes phase 1 simpler and not depending on AIP-44.
> >
> > The vote will last till next Friday 26th of April 2024 Noon CEST.
> >
> > J.
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@airflow.apache.org <mailto:
> dev-unsubscribe@airflow.apache.org>
> For additional commands, e-mail: dev-help@airflow.apache.org <mailto:
> dev-help@airflow.apache.org>
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@airflow.apache.org
> For additional commands, e-mail: dev-help@airflow.apache.org
>
Re: [VOTE] AIP-67 Multi-team deployment of Airflow components
Posted by Aritra Basu <ar...@gmail.com>.
+1 (non-binding)
--
Regards,
Aritra Basu
On Thu, Apr 18, 2024, 7:42 PM Bishundeo, Rajeshwar
<rb...@amazon.com.invalid> wrote:
> +1 (non-binding)
>
> -- Rajesh
>
>
>
>
>
>
> On 2024-04-18, 10:11 AM, "Vincent Beck" <vincbeck@apache.org <mailto:
> vincbeck@apache.org>> 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
>
>
> 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.org/confluence/display/AIRFLOW/AIP-67+Multi-team+deployment+of+Airflow+components
> <
> https://cwiki.apache.org/confluence/display/AIRFLOW/AIP-67+Multi-team+deployment+of+Airflow+components
> >
> >
> > Summarizing the most recent changes - responding to comments and doubts
> > raised during the discussion:
> >
> > * renamed it to be multi-team to clarify that this is the only case it
> > addresses
> > * splitting it into two phases: without and with internal API AIP-44
> (also
> > named as GRPC server)
> > * implifying the approach for Variables and Connections, where no changes
> > in Airflow will be needed to handle the DB updates.
> >
> > This makes phase 1 simpler and not depending on AIP-44.
> >
> > The vote will last till next Friday 26th of April 2024 Noon CEST.
> >
> > J.
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@airflow.apache.org <mailto:
> dev-unsubscribe@airflow.apache.org>
> For additional commands, e-mail: dev-help@airflow.apache.org <mailto:
> dev-help@airflow.apache.org>
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@airflow.apache.org
> For additional commands, e-mail: dev-help@airflow.apache.org
>
Re: [VOTE] AIP-67 Multi-team deployment of Airflow components
Posted by "Bishundeo, Rajeshwar" <rb...@amazon.com.INVALID>.
+1 (non-binding)
-- Rajesh
On 2024-04-18, 10:11 AM, "Vincent Beck" <vincbeck@apache.org <ma...@apache.org>> 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
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.org/confluence/display/AIRFLOW/AIP-67+Multi-team+deployment+of+Airflow+components <https://cwiki.apache.org/confluence/display/AIRFLOW/AIP-67+Multi-team+deployment+of+Airflow+components>
>
> Summarizing the most recent changes - responding to comments and doubts
> raised during the discussion:
>
> * renamed it to be multi-team to clarify that this is the only case it
> addresses
> * splitting it into two phases: without and with internal API AIP-44 (also
> named as GRPC server)
> * implifying the approach for Variables and Connections, where no changes
> in Airflow will be needed to handle the DB updates.
>
> This makes phase 1 simpler and not depending on AIP-44.
>
> The vote will last till next Friday 26th of April 2024 Noon CEST.
>
> J.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@airflow.apache.org <ma...@airflow.apache.org>
For additional commands, e-mail: dev-help@airflow.apache.org <ma...@airflow.apache.org>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@airflow.apache.org
For additional commands, e-mail: dev-help@airflow.apache.org
Re: [VOTE] AIP-67 Multi-team deployment of Airflow components
Posted by Vincent Beck <vi...@apache.org>.
+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.org/confluence/display/AIRFLOW/AIP-67+Multi-team+deployment+of+Airflow+components
>
> Summarizing the most recent changes - responding to comments and doubts
> raised during the discussion:
>
> * renamed it to be multi-team to clarify that this is the only case it
> addresses
> * splitting it into two phases: without and with internal API AIP-44 (also
> named as GRPC server)
> * implifying the approach for Variables and Connections, where no changes
> in Airflow will be needed to handle the DB updates.
>
> This makes phase 1 simpler and not depending on AIP-44.
>
> The vote will last till next Friday 26th of April 2024 Noon CEST.
>
> J.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@airflow.apache.org
For additional commands, e-mail: dev-help@airflow.apache.org