PreethamSanji commented on issue #57860: URL: https://github.com/apache/airflow/issues/57860#issuecomment-4989083138
Hi! I'd like to pick this up. Verified it's still current on `main`: `chart/templates/_helpers.yaml` hardcodes `key: connection` in the `secretKeyRef` for `AIRFLOW__DATABASE__SQL_ALCHEMY_CONN`, `AIRFLOW_CONN_AIRFLOW_DB`, `AIRFLOW__CELERY__RESULT_BACKEND`, and `AIRFLOW__CELERY__BROKER_URL`, so a CloudNativePG `Cluster` app secret (key `uri`) can't be used via `data.metadataSecretName`. Building on #54037 (stale-closed without review — will credit it): add `data.metadataSecretKey`, `data.resultBackendSecretKey`, and `data.brokerUrlSecretKey`, defaulting to "connection", fully backward compatible. One deliberate difference from #54037: the custom key will only apply when the corresponding `*SecretName` is user-provided — otherwise the env refs would point at a nonexistent key in the chart-created secrets, which always use connection. Includes chart unit tests (there's currently no coverage of these `secretKeyRef` keys, so this adds a regression guard for default behavior too), schema, values docs, and a production-guide note. Scope check: keep this to the three database/broker secrets per the issue title, leaving the `elasticsearch`/`opensearch` host secrets (same hardcoded key) as a possible follow-up, and leaving KEDA's `kedaConnection` untouched since it's a chart-managed key with its own format contract. Does it sound reasonable? -- 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]
