Taragolis commented on PR #23560: URL: https://github.com/apache/airflow/pull/23560#issuecomment-1124201085
@kaxil > but I would like to know more about your use-case. Can you expand on it please? Major use cases - lazy developers :-D. Usual cases is local development and QA struggling In local development usual we want to use the same connections as we use in remote dev and depend on project it could be 10 in other it could be 50. So we use secret backend to share between developers but as usual developer wanted re-define some certain connections (e.g. use their own snapshot of database). At that moment it really hardly possible, because secret backend always have a high priority. The current solutions: 1. dump of secrets backend for remote dev -> change it manually -> create new prefix -> repeat as soon as sources in remote changed 2. do not use secrets backends in remote dev / tests -> dump metadata db -> share across developers -> restore secrets -> repeat as sources in remote airflow changed For tests also the same, QA wanted to test in different environment (test, prod, pre-prod), but replace some connections Personally for me it would be nice if Environment Variables in search path have bigger priority but it is not possible to do this changes in core of Airflow, at least until Apache Airflow 3.y.z So my idea is give ability to change priority for secrets backends with minimum changes in Airflow and do not create breaking changes > Would [#19251 (comment)](https://github.com/apache/airflow/issues/19251#issuecomment-958992113) solve your issue? I think it could solve but required to implement the same things in every new project. (I'm also lazy developer) @dstandish > I don't think this is the right way to do this. I agree with you and also think it not the best solution. First of all because my solution expected that: 1. Exactly two default secrets backends 2. Zero or one alternative secrets backend If in one day in Airflow this changed - solution which I suggest wouldn't work as expected -- 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]
