1inuxoid commented on PR #29452: URL: https://github.com/apache/airflow/pull/29452#issuecomment-1426412030
> > `aws_conn_id_in`, `aws_conn_id_out` ??? and deprecate `aws_conn_id` for transfers operators within AWS? > > I'd maybe leave the existing aws_conn_id and make the new way an option with some checks to assert `aws_conn_id XOR (aws_conn_id_in and aws_conn_id_out)`. I don't think adding the option to specify an _out should require folks to update their existing code. I share the consideration of current usage of the operator and I agree that we should definitely keep the people, who are happy with using just one AWS connection untouched, however, the idea of introducing two more connection parameters so that there would never be a case, when all connections will be used at the same time, sounds quite weird to me. What would be the purpose of such generalisation? Out of all transfer operators only three of them operate entirely within AWS: `DynamoDBToS3Operator` `RedshiftToS3Operator` and `S3ToRedshiftOperator`. Another 15 have just one AWS connection, which is specified with `aws_conn_id`. We could even go as far as generalising all transfer operators, as there is always an **in** and an **out** with them, but that sounds like a major revamp. What does everyone think? How can we make the most practical first step? -- 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: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
