apache / apache/airflow

Follow-ups for Kustomize overlay smoke-test and Kerberos overlay

Open
#69,280 2 comments 0 reactions 0 assignees View on GitHub
area:helm-chart kind:meta
Dominant language
Python
Stars
46.9k
Forks
17.8k
Avg merge
2d 9h
Merged PRs (30d)
472

Description

### Body

# Follow-ups for Kustomize overlay smoke-test and Kerberos overlay (#67012)

PR #67012 ("Smoke test kustomize overlays and add tested Kerberos") merged with several review items deferred to follow-up work. This issue tracks them in one place.

Origin: https://github.com/apache/airflow/pull/67012

## Kerberos overlay

- [ ] **Complete the Kerberos to Kustomize migration.** The merged overlay only removes the `kerberos-keytab-secret.yaml` secret-creation logic, which is the simplest slice of the feature. A full migration still needs to:
- refresh credentials in the cache file (driven by the keytab file),
- wire the Airflow configuration into the existing cluster components,
- share and propagate the credential cache across components,
- move the Kerberos sidecars into the overlay.

Goal: demonstrate what a non-trivial overlay (unlike KEDA) looks like end to end.
- [ ] **Make the deploy order correct and documented.** Helm depends on the Secret produced by the overlay, so with `kerberos.enabled=true` a `helm` then `overlay` order fails because pods cannot attach the keytab from a Secret that does not exist yet. Today's smoke test hides this because the deployed chart is not configured with `kerberos.enabled=true`. Decide and document the required ordering per overlay, and make the real combination actually work.
- [ ] **Flip the Kerberos overlay README to past tense** once the Kerberos feature is removed from the chart.

## Smoke-test coverage

- [ ] **Add a baseline "environment still healthy" check.** Current tests confirm the kustomization renders and applies cleanly, but they do not confirm the pods come up healthy after the overlay is applied on top of a real Helm deploy. Add a general pod-status health baseline that asserts "applying this overlay did not break the environment."
- [ ] **Add integration tests that can modify Helm `values.yaml` before deploy.** To honestly promote an overlay to `tested` in its `STATUS.yaml`, tests need to deploy Helm with adjusted values (for example `kerberos.enabled=true`) and *then* apply the overlay, so kustomize and Helm are exercised together instead of in isolation.

## CI and infrastructure

- [ ] **Replace the `STATUS.yaml` "last-verified" date with a CI-driven status badge.** The date is a moving target. A badge sourced from a canary or CI job (like the central README's GitHub Actions badge) would be more meaningful and self-updating. Surface it in the overlays README.
- [ ] **Enforce the `ALLOWED_OVERLAY_IMAGES` allow-list via CODEOWNERS and branch protection.** The allow-list already fails fast on unlisted images, and adding an image requires a change to both `chart/` and `dev/`. Gating that with required CODEOWNERS approval is a repo or INFRA setting to configure separately from the code.
- [ ] **Split overlay tests into per-overlay matrix stages.** Today all overlays are applied in a single test stage, which makes mutually exclusive overlays (for example HPA vs KEDA) impossible to test together. Move to a matrix action, run only in canary, and gate each stage on its correlated file changes.
- [ ] **Move the allowed k8s image similar to `ALLOWED_KUBERNETES_VERSIONS`** (`airflow_breeze.global_constants`), while preserving the four-eyes review principle.

### Committer

- [x] I acknowledge that I am a maintainer/committer of the Apache Airflow project.

Contributor guide

Open the contributing guide

Research direction

Read PR #67012 and the Kustomize overlay smoke-test setup first, then inspect STATUS.yaml, Helm values.yaml, the overlay README, and the existing CI test stages. The checklist spans Kerberos migration, deploy ordering, health and integration coverage, status reporting, image governance, and test-matrix changes; completion requires independently defining and validating those follow-ups.

Written by the indexing model from the issue text.

Assessment

Tech stack
github-actions, helm, kubernetes, python, yaml
Domain
ci-cd, devops, infrastructure, testing
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.