Thanks for the feedback Jed, that's something I confess I had not thought about. It is a valid concern. What I can propose as a compromise is to leave the "move FAB auth manager to a separate provider" task to the end of the project and mark it as optional. In other words, we can build everything as described in the AIP but keep it in core Airflow as opposed to a separate provider. All the user management logic would still be "packaged" in the auth manager, and then when everything is implemented and done we can decide whether moving this FAB auth manager to a separate provider is feasible/a good idea.
What do you think? On 2023-06-12, 11:18 AM, "Jed Cunningham" <[email protected] <mailto:[email protected]>LID> wrote: Overall I'm happy with the proposal. One thing that concerns me though is moving the FAB auth manager into a separate provider. That auth manager will need to be able to hook into the db migration tooling, and we don't expose that to providers or plugins today. So if we do want to move it, we have to account for that as well. I feel the vast majority of the benefit here comes from being able to sub in another auth manager, but having the FAB one "not in core" isn't all that consequential at the end of the day. It would keep the strict version requirements of FAB in core though - pick your poison I guess :)
