PreethamSanji commented on issue #57860: URL: https://github.com/apache/airflow/issues/57860#issuecomment-4967706000
Hi! I'd like to pick this up — I've 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 directly via `data.metadataSecretName`. Proposed approach: Add` data.metadataSecretKey, data.resultBackendSecretKey`, and `data.brokerUrlSecretKey`, all defaulting to "connection", so behavior is fully backward compatible. They only matter when the corresponding *SecretName is user-provided; chart-created secrets keep using connection. `resultBackendSecretKey` falls back to `metadataSecretKey`, mirroring the existing` resultBackendSecretName` → `metadataSecretName `fallback. Update` values.schema.json`, the `values.yaml` doc comments (which currently document the connection key requirement), and the production guide docs accordingly. Scope questions before I start: (1) should this also cover the elasticsearch/opensearch secrets, which hardcode the same key, or keep this PR to the database credentials from the issue title? (2) I'd leave the KEDA `kedaConnection` key untouched since it's a chart-managed key with its own format contract, sound right? Plan: chart unit tests first (default renders connection; custom keys render through to all consuming env vars; fallback behavior), then the template change, verified with helm template. -- 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]
