Move DagBag to SDK and make it return SDK DAG objects - #53918
Conversation
|
The Databricks operator links are a mess… Not dealing with them right now, I believe they are already broken in 3.0 so we can just keep breaking it more. |
c269b3e to
e592a29
Compare
5e1a912 to
3c85372
Compare
c145194 to
5a9c7b7
Compare
|
Initially I planned to remove all db access, and move the DagBag class to SDK. However, after spending almost a week trying to debug some weird Kubernetes integration test failures, I give up. This no longer moves the class. I removed all database access in DagBag except |
5a9c7b7 to
e869185
Compare
jason810496
left a comment
There was a problem hiding this comment.
Nice! LGTM overall.
I removed all database access in DagBag except get_dag, where it checks whether a dag has expired and auto-refreshes it. I think we no longer needs this check since dagbag uses are ephemeral in Airflow now, but we will need to fix test cases to reflect that. This will be done in a later PR.
Does it mean if we want to remove db access for DagBag, we need to add another execution API route for checking whether the dag for given dag_id is expired?
The only db access in DagBag is orm_dag := DagModel.get_current, and orm_dag is used for checking is_expired.
|
I think we ultimately should remove the functionality. Scheduler and API server (the long running processes) already do not use this class now. The worker and dag parsing process are short-lived and this refreshing logic should not kick in at all. The main issue is to fix the tests so they reflect this, and implement necessary refreshing when a test expect it to happen automatically in-process (but now only happens in the dag processor in production circumstances). |
afd9cd4 to
28cdf2b
Compare
28cdf2b to
0b2bb73
Compare
read_dags_from_db=Trueget_dagMove DagBag to SDK (for use in dag parser and task runner)I give up