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