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] > >
