You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@airflow.apache.org by GitBox <gi...@apache.org> on 2021/11/23 00:35:19 UTC

[GitHub] [airflow] dimon222 commented on pull request #19725: Adjust built-in base_aws methods to avoid Deprecation warnings

dimon222 commented on pull request #19725:
URL: https://github.com/apache/airflow/pull/19725#issuecomment-976039982


   @potiuk 
   Correct.
   
   In general, I see no problem in any kind of refactoring if there's a legitimate reason for that. In our current scenario, however, we see that `iam` case that potentially wasn't considered (most likely just accidentally missed). I'm not much worried about `iam` as end Airflos user, but what I'm worried is about enormous spam of deprecation warnings in logs for components that I haven't touched - aws hook in cache (in this case the actual method calls for general scenario, skipping the IAM case).
   
   So the middleground I'm proposing here is:
   1. Main methods of hook will no longer raise false positives for deprecation and use new mechanic (see PR code itself). If user is utilizing these methods in his hook/aws based component implementations, (s)he will validly receive a proper deprecation warning. Once right time comes, for example for 3.x.x version cutoff the hook can be adjusted to drop the argument altogether and methods that are called in it will be modified to not pass anything in arg.
   2. `iam` scenario becomes "corner case" like it or not. If we want to polish that fragment we could consider stopping calls to respective method for `iam`, this way avoiding any corner case considerations for method's logic.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscribe@airflow.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org