-
Notifications
You must be signed in to change notification settings - Fork 16.4k
Remove old lineage stuff #45260
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
Remove old lineage stuff #45260
Conversation
|
When attempting to remove the lineage logic from the core module, I noticed that it causes failures in tests related to OpenLineage listener capturing hook-level lineage (#41482). For example, removing airflow/airflow/models/baseoperator.py Lines 705 to 739 in 0efd9e6
Results in the following test failure:
It seems OpenLineage is still coupled with the lineage module and might need to be moved to After some experimentation, implementing an I’m not sure if this is a suitable long-term solution for maintaining OpenLineage compatibility while cleaning up the lineage module ? |
7975d5a to
727a6c1
Compare
727a6c1 to
2ec66f0
Compare
|
The CI failure is caused by a flaky K8s test (#45145) and a breaking change in the compatibility tests for providers 2.9.3 and 2.10.4 . Should we fix the tests to pass the compatibility checks, or is it acceptable to ignore the compatibility tests since all tests for 3.0 have passed ? |
2.9.3 or 2.3.9. If it's 2.9.3, then we'll need to fix it as providers will still support airflow 2 for some time |
Sorry for the typo, I mean 2.9.3 and 2.10.4 . Thanks for reply, if then I will fix the test. |
|
We should not remove the entire lineage mechanism. The issue is only meant to remove the old lineage constructs in |
|
Just as TP said. Removing airflow/lineage/hook.py is wrong |
2ec66f0 to
7274e30
Compare
|
@jason810496 I rebased it -> we found and issue with @jscheffl with the new caching scheme - fixed in #45347 that would run "main" version of the tests. |
7274e30 to
b32fd1a
Compare
|
Fixed: I only moved One small question: Does this PR need to be backported to 2.10 ? |
2cb6d39 to
f527be9
Compare
|
Hi @jason810496, I just found the PR we discussed yesterday. #44720 I think this one would be useful for this PR. |
f527be9 to
4367e2a
Compare
No since you only moved the classes. The providers are always released from main, and it’s OK for those classes to be available in two places in 2.10. |
fcb5625 to
9545aa1
Compare
9545aa1 to
7158e1e
Compare
* Move airflow.lineage.entities to compact provider * Fix providers and corresponding test import path * Fix core test import path * Fix import path in related docs
* Move airflow.lineage.entities to compact provider * Fix providers and corresponding test import path * Fix core test import path * Fix import path in related docs
* Move airflow.lineage.entities to compact provider * Fix providers and corresponding test import path * Fix core test import path * Fix import path in related docs
* Move airflow.lineage.entities to compact provider * Fix providers and corresponding test import path * Fix core test import path * Fix import path in related docs
closes: #44983
^ Add meaningful description above
Read the Pull Request Guidelines for more information.
In case of fundamental code changes, an 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 a newsfragment file, named
{pr_number}.significant.rstor{issue_number}.significant.rst, in newsfragments.