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

[DPTOOLS-604] Remove deprecate warning #59

Merged
merged 1 commit into from
May 21, 2018

Conversation

feng-tao
Copy link

Not sure why we have these warning in airflow(apache#1285).

But we won't show it in our lyft repo:)

@feng-tao
Copy link
Author

@@ -36,9 +36,9 @@

# show Airflow's deprecation warnings
warnings.filterwarnings(
action='default', category=DeprecationWarning, module='airflow')
action='ignore', category=DeprecationWarning, module='airflow')

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Rather than ignore these, could we just fix them?

Copy link
Author

@feng-tao feng-tao May 21, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The warning comes from here(https://github.com/lyft/incubator-airflow/blob/data-platform-upgrade/airflow/models.py#L1977-L1985) which comes from users passing un-named arguments to operators. The original pr checked in to upstream airflow in 2016 and we still saw many operators passing un-named arguments.

I think the fix could be :
option 1: remove the warning in our repo(remove https://github.com/lyft/incubator-airflow/blob/data-platform-upgrade/airflow/models.py#L1977-L1985)
option 2: similar to this pr
option 3: fix all the existing dag operator usage and prevent them from passing un-named arguments.
option 4: check with the upstream airflow community and see if we still want to disable using *args and *kargs as the original pr is in 2016 and targeted for airflow 2.0(no timeline). If yes, we could start with fixing the upstream usage first and then bring it back to lyft repo.

I am fine with option 1 and 2, but option 3, 4 seems to be non-trivial. What do you think?

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

All the code that is passing un-named args are in the etl code base, not part of upstream Airflow, right? If so, I'd be in favor of actually fixing them. I worry that hiding the warnings will hide real bugs from users writing DAGs.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it involves first fixing all the existing operators(e.g https://github.com/lyft/etl/blob/master/lib/lyftdata/airflow/plugins/operators/anodot_operator.py), then fix all the usage for the dags which use kwargs in operators. And we can't fix in upstream(e.g remove kwargs and args in BaseOperator), we can't prevent users to continue using kwargs even after we fix all the issues. Let me send out an email to upstream alias and check if it is still on the roadmap to remove kwargs in BaseOperator.

And I am not sure how this message could user debug their DAG as well. One thing I worry about your approach is that it will touch many dags which could cause unknown dag failure as we are not familiar with the dags.

@astahlman
Copy link

👍

@feng-tao feng-tao merged commit 835cb32 into data-platform-upgrade May 21, 2018
@eschachar eschachar deleted the tfeng_remove_warning branch September 24, 2022 22:33
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants