Implement Fab provider views in airflow 3

[pierrejeambrun]

Context

This is a front-end story.

Depends on: #44881

FabAuthManager register admin views leveraging FAB, to enable this:

The front end code need to be developed (most likely inside the provider), and we need to find a way to register react code from the provider into the main react application. The ideal way would be to leverage the new front-end plugin system.

That might be a two step process:

• Part 1: Leverage the new plugin system for the react UI from the providers (fab) to be able to register a new dummy front-end page (POC). (Requires the plugin system)
• Part 2: Develop all the admin pages necessary from the fab provider (user, role, permissions, etc...). Thanks to Part 1 this code should live directly inside the provider.

Fallback

If the plugin system if not ready or if this happen to be too complex (packing of providers with react code etc...) we could temporarily:
Code this front-end pages in the core UI, and depending on the auth manager used, display them or not. That's less scalable because if other providers need to register new views, we will have their code into core UI with conditional rendering, which isn't great.

Committer

• I acknowledge that I am a maintainer/committer of the Apache Airflow project.

[pierrejeambrun]

cc: @vincbeck

[pierrejeambrun]

good first issue for the Part 2, to drag attention, a lot of interesting PRs to make there.

[pierrejeambrun]

cc: @jedcunningham

Update this will most likely not be done like this to avoid re-implementing admin views in react. We will embed the flask rendered pages in the new UI.

[vincbeck]

cc: @jedcunningham

Update this will most likely not be done like this to avoid re-implementing admin views in react. We will embed the flask rendered pages in the new UI.

I am happy to discuss this with you but I'd be careful if we go down that path. Explanations.

Going down that path means that an auth manager needs to use Flask to create custom views. To me, this is a bit weird to explain to users that if they want to create an auth manager, they need to use Flask, which will then be rendered in Fast api. One solution could be to offer both mode (we keep the Flask option for legacy auth managers such as Fab and we also provide the option to create custom views with Fast api). I'd strongly encourage going with this option. But this option is not perfect either. Keeping Flask as an option for auth managers means:

• Flask wont be removed from Airflow 3, we will still have Flask as part of dependencies
• Some methods in the base_auth_manager.py such as get_api_endpoints (used for an auth manager to extend the Rest API) depend on Flask (it returns a Flask Blueprint). If we need to keep this method for legacy auth managers, we wont be able to remove it before Airflow 4 (breaking change)

[jedcunningham]

Sorry for the delay here, I'd intended to get a discussion going on this but y'all beat me too it :)

The auth mananger interface should just have a way to accept fastapi subapps - that leaves the specifics to the auth managers themselves. Some could use fastapi native subapps, others could wrap flask/fab/etc with WSGIMiddleware. We could document how to mount flask, or not. But this removes the dependency on flask/fab if it's not actually used.

[vincbeck]

Sorry for the delay here, I'd intended to get a discussion going on this but y'all beat me too it :)

The auth mananger interface should just have a way to accept fastapi subapps - that leaves the specifics to the auth managers themselves. Some could use fastapi native subapps, others could wrap flask/fab/etc with WSGIMiddleware. We could document how to mount flask, or not. But this removes the dependency on flask/fab if it's not actually used.

That should work :)

[vincbeck]

See #45009

[vincbeck]

I think we can close this one? As far as I know we will not do it?

[jedcunningham]

Yeah, think we are good on this one.