potiuk edited a comment on issue #12611: URL: https://github.com/apache/airflow/issues/12611#issuecomment-988403817
Yeah. I also think it's not really AIP-worthy. But this is very good point with the multi-tenancy interaction I am performing an inventory of stuff that will be afected by multitenancy proposals and I will take a look on the notifications as well then and think about it (and for sure we will raise it in the API AIP). While the notification mechanism (emails) use now the "Connection" for authentication, it would be good indeed to "hide" that information (login password) from the caller - if it is a worker, or "DagProcessor" or "Triggerer" as this is really a "shared/global" configuration rather than per-task one (and tasks essentially do not need access to it unless they want to send email directly using their own connection). As such this is definitely part of the 3rd AIP that follows (fine-grained access to resources) where this one falls in). And then whe we implement such fine-grained access we could potentially move it to the same place where other "Internal API calls" will be executed (which brings me more to the point of our recent discussions with @mhenc that we should not call it "DB-API" but "Internal API" sounds much more appropriate. So we will keep an eye on that one. However, ine thing that might be good to mention is to make it part of the Provider's interface. We already have a number of Providers (Slack, AWS, Azure, DataDog) - and similarly as with other "core-extensions" those seem to be good candidated to land there as another "core extensions" that are provided by community providers https://airflow.apache.org/docs/apache-airflow-providers/core-extensions/index.html (as @ashb mentioned similar to operator base links, also secret backends, auth etc. ). Even if the notification "backends" would not require an explicit discovery/registration, it's good to have such a Provider's capability list - if anything for the documentation/discovery (with provider.yaml information the documentation can be easily automated for any new implementation of "notifier". It's also nice for API/CLI/UI discovery of currently installed capabilllities with providers. -- 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]
