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 >
