jaketf commented on issue #10454: URL: https://github.com/apache/airflow/issues/10454#issuecomment-685232736
I think the approach of subclassing k8s pod operator is far from how we typically build airflow integrations and the heavy reliance on k8s secrets as opposed to leaning in on airflow secrets managers might be overly opinionated. I guess I'd like to ask does this seem like something that belongs in airflow core or something that belongs as an opinionated plugin released elsewhere? Due to the wide variety of binaries folks end up relying on in their terraform scripts (even perhaps different terraform version in different DAGs), the large permissions footprint required I think it is difficult to develop a very general integration that gives the user enough flexibility to meet their security needs. Taking a step back: I am a concerned that I'm sort of making up these requirements based on my own speculation (I have no real connection to hashi and haven't worked w/ a gcp customer who directly asked for this feature but rather it evolved from [this discussion](https://github.com/apache/airflow/pull/9593#issuecomment-667906041)). Is there a good way to crowdsource from the community what their interest / requirements are for an airflow/terraform integration are? Is this best done in the dev-list? user-list? slack sig? Is there a good way for airflow community to engage a provider like hashi in helping design / develop this based on what they might hear from their customers? ---------------------------------------------------------------- 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. For queries about this service, please contact Infrastructure at: [email protected]
