anzinmhd commented on code in PR #74912:
URL: https://github.com/apache/airflow/pull/74912#discussion_r4303553959
##########
chart/files/pod-template-file.kubernetes-helm-yaml:
##########
@@ -122,7 +122,7 @@ spec:
- name: KRB5CCNAME
value: {{ include "kerberos_ccache_path" . | quote }}
{{- end }}
- {{- include "standard_airflow_environment" . | indent 6}}
+ {{- include "standard_airflow_environment" (merge (dict
"ExcludeDatabase" true) .) | indent 6 }}
Review Comment:
Thanks for checking the Kerberos cases and sharing the test matrix and
commit. You're right that those containers still render metadata Secret
references, so the current change does not remove the dependency for
Kerberos-enabled pods.
I investigated whether excluding the variables from those containers is
sufficient at runtime. Both invoke `airflow kerberos` (`-o` for the init
container). The command uses `@cli_utils.action_cli`, whose default
`check_db=True` runs migration checking and log-template synchronization before
the Kerberos command body. This path is also present in the [3.2.2 CLI
wrapper](https://github.com/apache/airflow/blob/3.2.2/airflow-core/src/airflow/utils/cli.py).
I ran two isolated tests using the released `apache/airflow:3.3.2` image,
with both database environment variables absent:
- With migration checks explicitly disabled, log-template synchronization
skipped the absent table and execution reached `kinit`. It then failed because
no Kerberos realm was configured.
- With the deployed chart's `airflow.cfg` mounted and no migration-check
override, `database.check_migrations` resolved to `True`. The command exited
before ticket initialization with: `Database migration required. Please run
airflow db migrate.`
These were CLI container tests, not a complete Kerberos-enabled cluster
test. They do not establish that Kerberos inherently needs the metadata Secret,
but they show that removing the references alone is insufficient with the chart
configuration tested. The fallback database fails the default migration check.
Passing `ExcludeDatabase` to the two Kerberos containers would therefore
remove the Kubernetes Secret references but leave a CLI startup failure under
the tested configuration. The rendering tests verify the generated environment,
but do not exercise that startup path. Removing these references requires
addressing and validating the Kerberos CLI database initialization behavior as
well; the template-only change is insufficient.
--
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]
