eladkal commented on PR #33680: URL: https://github.com/apache/airflow/pull/33680#issuecomment-1695061486
> I think that this actually adds some complexity for users, as they have to understand two largely different mechanisms for mounting secrets. I also feel like it removes a lot of configurability with the existing secrets, such as mounting in env vs. a volume, mounting a subset of fields etc. Since we already have all of this in place in this operator (with secrets: list[Secret]), why not re-use it? Any design choice you take has advantages and disadvantages. I am a strong advocate for allowing referencing Airflow conn_id. From functionality point of view it makes no sense that we have a connection details stored in Airflow but for K8s pod users will have to redefine it somewhere else. The how to make this work in K8s is another topic. > It indeed crossed my mind too, and it is quite a bit worrying, I quite agree. I know @eladkal 's team approach was exactly this, they had jobs that cleaned old secrets. Unfortunately K8S has no auto-cleaninig of secrets. It would be a great feature to have. But we don't.... Yes but it wasn't that much of a pain. It's a simple script to run once a week and it takes less than 1 min to finish. -- 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]
