Implements AwsBaseOperator and AwsBaseSensor#34784
Conversation
There was a problem hiding this comment.
It is also might be a good idea to make this classes internal only.
There was a problem hiding this comment.
And wondering about module naming because I a bit confused:
Suggestion in old PR use base_aws: #24246 (comment)
Naming for Base Trigger: airflow.providers.amazon.aws.triggers.base.AwsBaseWaiterTrigger
cc @ferruzzi @vincbeck @o-nikolas
There are only two hard things in Computer Science: cache invalidation and naming things
There was a problem hiding this comment.
Agree, naming is hard xD. I am fine with base_aws.py. It could be also:
- base_operator.py
- base.py
There was a problem hiding this comment.
It is also might be a good idea to make this classes internal only.
+1
There was a problem hiding this comment.
This changes also required to make changes in airflow.providers.amazon.aws.triggers.base.AwsBaseWaiterTrigger as follow-up.
That is also why I make accept botocore_config as dictionary and not botocore.config.Config object
ferruzzi
left a comment
There was a problem hiding this comment.
Left some suggestions. We've discussed an AwsBaseOperator a few times and kept putting it off, there may be some more suggestions coming once I check my notes on what I was going to put into it.
As always, thanks for your thought and effort on the provider package contribution. 👍
There was a problem hiding this comment.
I think this is repeating itself, but maybe I'm missing something.
There was a problem hiding this comment.
Using the default AWS Connection id aws_default (as long as it is created and remains untouched by the user) also uses the default boto3 behaviour. Might be worth mentioning.
There was a problem hiding this comment.
Maybe we could try to rewrite it to something shorter with reference to AWS Connection, like we have in other providers, e.g. Slack
airflow/airflow/providers/slack/operators/slack_webhook.py
Lines 42 to 43 in ed6a4fd
ferruzzi
left a comment
There was a problem hiding this comment.
Looks like my comments have all been addressed. Thanks.
eladkal
left a comment
There was a problem hiding this comment.
I assume followup PR would be to change AWS operators/hooks to inherit from the base classes?
We need also doc update to explain how to set the botocore parameters
There was a problem hiding this comment.
You need to move these to the BASE_CLASSES
There was a problem hiding this comment.
I was a bit blind 🤣
Yep
I think it would be a good idea to add generic information here: https://airflow.apache.org/docs/apache-airflow-providers-amazon/stable/operators/index.html as soon as we change existed Operators, so them will have same sets of generic parameters:
|
There was a problem hiding this comment.
Agree, naming is hard xD. I am fine with base_aws.py. It could be also:
- base_operator.py
- base.py
There was a problem hiding this comment.
Out of curiosity. Why from None?
There was a problem hiding this comment.
Just for skip previous traceback, e.g. if developer set aws_hook_class then it failed with TypeError on issubclass and traceback will contain information about error which raised from issubclass
There was a problem hiding this comment.
I see, thanks for the explanation
There was a problem hiding this comment.
I had to research that one too, I have never seen that in use. It's kinda handy.
d38cde3 to
63052fa
Compare
Co-authored-by: D. Ferruzzi <[email protected]>
63052fa to
126a1f5
Compare
|
In 126a1f5 split logic into two classes, for reduce repeatable code in |
| Only for internal usage, this class might be changed, renamed or removed in the future | ||
| without any further notice. |
There was a problem hiding this comment.
Regarding this, should we change the class name to _AwsBaseOperator?
Same for the Sensor and mixin classes
There was a problem hiding this comment.
There is kind of tradeoff between common Python's agreement about internal variables/classes/methods and airflow public models. _ shows that is internal stuff however IDE doesn't like this imports even with the same package (I guess static checks is fine) in the other hand we have some methods and class in core which do no prefixed by _ but have a description and :meta private:.
There is also maybe a good idea to make this stuff public after a while for create custom operators, but for now I would rather keep it internal only
In the end no one could stop end users to use this stuff directly
There was a problem hiding this comment.
Using the default AWS Connection id aws_default (as long as it is created and remains untouched by the user) also uses the default boto3 behaviour. Might be worth mentioning.
Co-authored-by: Niko Oliveira <[email protected]>
syedahsn
left a comment
There was a problem hiding this comment.
Looks good to me. I'd be interested to see how much this affects new and existing operators and sensors.
Continuation #24246
This base operators and sensors might help to resolve inconsistency in multiple operators and sensors:
aws_conn_idregioninstead ofregion_nameIn additional this implementation propagate additional parameters into the hook:
botocore_config-> Hookconfigverify-> HookverifyNote
AwsBaseSensorcreated by "old methodic"AwsBaseOperatorI've tried to create Mixin class however it not works well breaks something in BaseOperator
If someone know how to implements it by DRY, without use additional Metaclasses and/or class decorators feel free to suggest.
^ 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.