dstandish commented on code in PR #23560:
URL: https://github.com/apache/airflow/pull/23560#discussion_r901151998


##########
docs/apache-airflow/security/secrets/secrets-backend/index.rst:
##########
@@ -101,8 +143,8 @@ Roll your own secrets backend
 A secrets backend is a subclass of 
:py:class:`airflow.secrets.BaseSecretsBackend` and must implement either
 :py:meth:`~airflow.secrets.BaseSecretsBackend.get_connection` or 
:py:meth:`~airflow.secrets.BaseSecretsBackend.get_conn_value`.
 
-After writing your backend class, provide the fully qualified class name in 
the ``backend`` key in the ``[secrets]``
-section of ``airflow.cfg``.
+After writing your backend class, provide the fully qualified class name in 
the ``backend`` key or provide

Review Comment:
   > Which more like for me I don't know how to do it, but think better and do 
it better - that is last thing that I or someone else expects see on review 
(both on open source or commercial development) . If you have suggestion how to 
do it better right now without rewrite a lot of stuff - feel free to suggest.
   
   I'm just saying on the face of it, it seems it should be possible to update 
the config approach for secrets backend without keeping the old one live.  And 
no, I did not investigate exactly how you should do this.
   
   > I'm absolutely agree with your idea that we need to have only one approach 
with deprecated values.
   But right now Secrets Backend doesn't use this approach in anyway and 
without changes in AirflowConfigParser it is hardly possible.
   
   What i'm saying is that we should not maintain two config styles 
concurrently, that the old one should be deprecated, and the nuts and bolts of 
exactly how I'm less concerned with.
   
   I may be able to explore solutions next week.  In the meantime who knows 
maybe someone else will support your approach. 
   
   Thanks



-- 
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]

Reply via email to