The operator is a thin wrapper around their SDK. The qubole SDK makes heavy
use of **kwargs, and the operator just passes them through.
Short of writing our own operator with named Params to keep the base operator
happy and then delegate to the qubole sdk, there’s no other way to silence the
w
Doesn't this warning come from the BaseOperator class -
https://github.com/apache/incubator-airflow/blob/master/airflow/models.py#L2511
?
Are you passing unused arguments to the QuboleOperator, or do you not
control the instantiation of those operators?
Chris
On Fri, Sep 28, 2018 at 7:39 PM Sean
Haha yes, good point. Thanks!
Sean
On 9/28/18, 6:13 PM, "Ash Berlin-Taylor" wrote:
Sounds good for your use, certainly.
I mainly wanted to make sure other people knew before blindly equipping a
foot-canon :)
-ash
> On 29 Sep 2018, at 00:09, Sean Carey wrote
Sounds good for your use, certainly.
I mainly wanted to make sure other people knew before blindly equipping a
foot-canon :)
-ash
> On 29 Sep 2018, at 00:09, Sean Carey wrote:
>
> Thanks, Ash. I understand what you're saying. The warnings are coming from
> the Qubole operator. We get a lo
Thanks, Ash. I understand what you're saying. The warnings are coming from
the Qubole operator. We get a lot of this:
PendingDeprecationWarning: Invalid arguments were passed to QuboleOperator.
Support for passing such arguments will be dropped in Airflow 2.0. Invalid
arguments were:
*args:
What deprecation warnings are you getting? Are they from Airflow itself (i.e.
things Airflow is calling like flask_wtf, etc) or of your use of Airflow?
If it is the form could you check and see if someone has already reported a
Jira issue so we can fix them?
https://issues.apache.org/jira/issue
Hello,
I’ve been looking for a way to suppress the PendingDeprecationWarning messages
cluttering our airflow logs and I have a working solution which I thought I
would share.
In order to do this, you first need to configure airflow for custom logging
using steps 1-4 here:
https://airflow.read
