Sounds good to me. Hopefully we can make it happen, but we give ourselves an escape hatch :)
On Fri, Jun 16, 2023 at 9:45 AM Beck, Vincent <vincb...@amazon.com.invalid> wrote: > 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" <j...@astronomer.io.inva > <mailto:j...@astronomer.io.inva>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 :) > > > >
