+1 to moving it to providers, since it gives more flexibility. Thanks, Utkarsh Sharma
On Fri, Nov 17, 2023 at 5:50 PM Jarek Potiuk <[email protected]> wrote: > Ah ... put it in a wrong thread, sorry :) ... > > On Fri, Nov 17, 2023 at 12:39 PM Jarek Potiuk <[email protected]> wrote: > > > OK. Seeing that - I think I will do the next step - I will point this > > discussion to at the discord of Dask and see if there is a volunteer > there > > who would like to take on fixing the "Quarantined" issue > > https://github.com/apache/airflow/issues/32778 -> we have the flaky > tests > > currently marked as "Quarantined - so it is not really running in regular > > tests anyway. If there is no-one stepping in and wanting to commit to > take > > over and manage fixing of similar issues, I will start a voting thread > for > > removal, > > > > For me that is an ultimate (and very concrete) "checkpoint" if the Dask > > community is up to the task in our repo. And if they are not - they are > > always free to fork it and maintain their own provider. I think it's a > very > > fair approach and quite reasonable expectation - taking into account that > > we have so little usage and so many problems. > > > > J > > > > On Fri, Nov 17, 2023 at 10:28 AM Wei Lee <[email protected]> wrote: > > > >> +1 for this moving it. It gives us more flexibility on both the core and > >> provider sides. > >> > >> Best, > >> Wei > >> > >> > On Nov 17, 2023, at 9:15 AM, Jarek Potiuk <[email protected]> wrote: > >> > > >> > I am all for it. As we saw already and we see it more in the future - > >> > moving code of out of Airflow core to provider and having separate > >> > provider's release cycle and lifecycle is generally beneficial: > >> > > >> > * dependencies can be more decoupled - even if we pin FAB with a > >> particular > >> > version of provider, our users can freely change provider version > >> > without updating airflow and the other way round - update airflow > >> without > >> > changing provider version (thus without changing FAB). > >> > * we will be able to remove FAB in the future from active maintenance > - > >> > similarly to discussed dask executor we can stop maintaining FAB > >> provider > >> > in the future (no plans now of course - but it might happen - > >> especially if > >> > we will implement a way to migrate current USER/ROLE of FAB to > something > >> > else > >> > > >> > I think we've learned already a lot on how to manage lifecycle of > >> providers > >> > and have a number of tools and processes, so I think it will not be > too > >> > problematic. > >> > > >> > J. > >> > > >> > > >> > > >> > On Tue, Nov 14, 2023 at 9:46 PM Beck, Vincent > >> <[email protected]> > >> > wrote: > >> > > >> >> Hello, > >> >> > >> >> I am sending this email to gather feedbacks/concerns on what is going > >> to > >> >> happen regarding AIP-56 ( > >> >> > >> > https://cwiki.apache.org/confluence/display/AIRFLOW/AIP-56+Extensible+user+management > >> ). > >> >> The majority of the work related to AIP-56 is now completed. As a > >> summary, > >> >> all the code related to user authentication and user authorization > has > >> been > >> >> packaged in a new component called "FAB auth manager" ( > >> >> > >> > https://github.com/apache/airflow/blob/main/airflow/auth/managers/fab/fab_auth_manager.py > >> ). > >> >> Now, all user authentication and user authorization operations are > >> done in > >> >> this FAB auth manager. The purpose of having this new component is to > >> be > >> >> able to plug (and/or create) another "auth manager" if desired. > >> >> > >> >> For simplification reasons, this FAB auth manager is still in core > >> Airflow > >> >> under "airflow.auth.managers.fab" ( > >> >> > https://github.com/apache/airflow/tree/main/airflow/auth/managers/fab) > >> >> but the ultimate plan is to move the module > >> "airflow.auth.managers.fab" to > >> >> a new provider. Of course, this new provider would still be installed > >> by > >> >> default in Airflow and will have no impact for the users. > >> >> > >> >> An issue had been created for that work and a discussion has started > >> but I > >> >> wanted to increase the audience and potentially get more > >> feedbacks/concerns > >> >> before actually doing so: > >> https://github.com/apache/airflow/issues/32210. > >> >> In this issue you will also find the motivations behind moving this > >> code to > >> >> a new provider. > >> >> > >> >> Cheers, > >> >> Vincent > >> >> > >> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: [email protected] > >> For additional commands, e-mail: [email protected] > >> > >> >
