Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Adds mechanism for provider package discovery. #12383

Merged
merged 1 commit into from
Nov 17, 2020

Conversation

potiuk
Copy link
Member

@potiuk potiuk commented Nov 16, 2020

This is a simple mechanism that will allow us to dynamically
discover and register all provider packages in the Airflow core.

Closes: #11422


^ Add meaningful description above

Read the Pull Request Guidelines for more information.
In case of fundamental code change, Airflow Improvement Proposal (AIP) is needed.
In case of a new dependency, check compliance with the ASF 3rd Party License Policy.
In case of backwards incompatible changes please leave a note in UPDATING.md.

@potiuk
Copy link
Member Author

potiuk commented Nov 16, 2020

This is a much better/faster/more versatile version of provider manager - which will allow for discovery and registration of provider packages! It is based on the provider.yaml files that we have in each provider for documentation but we should be able also to extend it to contain the classes that should be registered.

Let me know your comments!

@github-actions
Copy link

The Workflow run is cancelling this PR. Building images for the PR has failed. Follow the the workflow link to check the reason.

@potiuk
Copy link
Member Author

potiuk commented Nov 16, 2020

Hey @ashb @kaxil @dimberman @turbaszek @mik-laj - we discussed it at the 2.0 call, I know there was my POC done differently and there were some ideas with pluggr, but I think using the metadata from provider.yaml that @mik-laj added is a super-simple and very powerful.

I added the provider discovery mechanism - I made sure it works with implicit packages and supports multiple location of installation of provider packages (so you can have provider packages installed in several locations as well as locally and it should work). Also I am reading the provider.yaml using importlb.resources (from 3.7 but I added optional backport for 3.6).

This means that this provider.yaml discovery should work regardless of the installation method of the packages (so it will even work if the packages are installed as .zip files, which is theoretically supported).

This is very versatile and simple and it should allow us to do things like:

  • developing API to discover which providers are installed - including description/version/ even all the information that is now part of the documentation
  • displaying installed providers in the UI (including all the extra information)
  • CLI to inspect the providers installed as well
  • refreshing list of providers on signal or webserver reload or periodically (it is super-fast)

Providing that the idea will be ok for others, I think I can have most of the discovery and registration done by tomorrow.

@potiuk
Copy link
Member Author

potiuk commented Nov 16, 2020

Let me know WDYT

airflow/providers_manager.py Show resolved Hide resolved
airflow/providers_manager.py Outdated Show resolved Hide resolved
airflow/providers_manager.py Outdated Show resolved Hide resolved
airflow/providers_manager.py Show resolved Hide resolved
@potiuk potiuk force-pushed the add-package-discovery branch 2 times, most recently from 06dafa4 to 4131808 Compare November 17, 2020 08:34
@potiuk
Copy link
Member Author

potiuk commented Nov 17, 2020

Comments applied @ashb

@github-actions github-actions bot added the full tests needed We need to run full set of tests for this PR to merge label Nov 17, 2020
@github-actions
Copy link

The PR needs to run all tests because it modifies core of Airflow! Please rebase it to latest master or ask committer to re-run it!

@potiuk potiuk force-pushed the add-package-discovery branch 2 times, most recently from f6431bb to fbdf2ab Compare November 17, 2020 12:19
@github-actions
Copy link

The Workflow run is cancelling this PR. It has some failed jobs matching ^Pylint$,^Static checks,^Build docs$,^Spell check docs$,^Backport packages$,^Provider packages,^Checks: Helm tests$,^Test OpenAPI*.

@github-actions
Copy link

The Workflow run is cancelling this PR. It has some failed jobs matching ^Pylint$,^Static checks,^Build docs$,^Spell check docs$,^Backport packages$,^Provider packages,^Checks: Helm tests$,^Test OpenAPI*.

@potiuk potiuk force-pushed the add-package-discovery branch 3 times, most recently from 0738790 to 12d68ea Compare November 17, 2020 14:46
@potiuk
Copy link
Member Author

potiuk commented Nov 17, 2020

@ashb -> any more comments on this one?

@github-actions
Copy link

The Workflow run is cancelling this PR. It has some failed jobs matching ^Pylint$,^Static checks,^Build docs$,^Spell check docs$,^Backport packages$,^Provider packages,^Checks: Helm tests$,^Test OpenAPI*.

@github-actions
Copy link

The Workflow run is cancelling this PR. It has some failed jobs matching ^Pylint$,^Static checks,^Build docs$,^Spell check docs$,^Backport packages$,^Provider packages,^Checks: Helm tests$,^Test OpenAPI*.

@github-actions
Copy link

The Workflow run is cancelling this PR. It has some failed jobs matching ^Pylint$,^Static checks,^Build docs$,^Spell check docs$,^Backport packages$,^Provider packages,^Checks: Helm tests$,^Test OpenAPI*.

@github-actions
Copy link

The Workflow run is cancelling this PR. It has some failed jobs matching ^Pylint$,^Static checks,^Build docs$,^Spell check docs$,^Backport packages$,^Provider packages,^Checks: Helm tests$,^Test OpenAPI*.

@github-actions
Copy link

The Workflow run is cancelling this PR. It has some failed jobs matching ^Pylint$,^Static checks,^Build docs$,^Spell check docs$,^Backport packages$,^Provider packages,^Checks: Helm tests$,^Test OpenAPI*.

@github-actions
Copy link

The Workflow run is cancelling this PR. It has some failed jobs matching ^Pylint$,^Static checks,^Build docs$,^Spell check docs$,^Backport packages$,^Provider packages,^Checks: Helm tests$,^Test OpenAPI*.

@github-actions
Copy link

The Workflow run is cancelling this PR. It has some failed jobs matching ^Pylint$,^Static checks,^Build docs$,^Spell check docs$,^Backport packages$,^Provider packages,^Checks: Helm tests$,^Test OpenAPI*.

@github-actions
Copy link

The Workflow run is cancelling this PR. It has some failed jobs matching ^Pylint$,^Static checks,^Build docs$,^Spell check docs$,^Backport packages$,^Provider packages,^Checks: Helm tests$,^Test OpenAPI*.

@github-actions
Copy link

The Workflow run is cancelling this PR. It has some failed jobs matching ^Pylint$,^Static checks,^Build docs$,^Spell check docs$,^Backport packages$,^Provider packages,^Checks: Helm tests$,^Test OpenAPI*.

@github-actions
Copy link

The Workflow run is cancelling this PR. It has some failed jobs matching ^Pylint$,^Static checks,^Build docs$,^Spell check docs$,^Backport packages$,^Provider packages,^Checks: Helm tests$,^Test OpenAPI*.

This is a simple mechanism that will allow us to dynamically
discover and register all provider packages in the Airflow core.

Closes: apache#11422
@potiuk
Copy link
Member Author

potiuk commented Nov 17, 2020

I'd merge it now and I can address any more comments in the follow-up PRs where I add those discovery "actions"

@potiuk potiuk merged commit 2c0920f into apache:master Nov 17, 2020
@potiuk potiuk deleted the add-package-discovery branch November 17, 2020 17:48
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
full tests needed We need to run full set of tests for this PR to merge
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Automatically discover available packages
4 participants