mihirduvedi commented on issue #34048: URL: https://github.com/apache/airflow/issues/34048#issuecomment-5191604376
I would like to take the design and implementation follow-up for this issue. I rechecked current `main`, this issue's timeline, and open PRs: #34048 is now in the **Airflow Helm Chart 2.0.0** milestone, the chart itself is at 2.0.0, and I found no open PR implementing the recommended-label migration. I did find #70205, which is actively changing object-versus-pod label plumbing on the same workload templates. Its goal is distinct from this issue, but I would sequence this work after or around that PR rather than duplicate or conflict with its `labels`/`podLabels` changes. Before editing the chart-wide label surface, could a maintainer confirm which compatibility direction is intended for Chart 2.0? 1. **Additive migration:** add the five labels shown in the issue (`app.kubernetes.io/part-of`, `app.kubernetes.io/component`, `app.kubernetes.io/instance`, `helm.sh/chart`, and `app.kubernetes.io/managed-by`) while retaining the legacy labels and all current selector keys. 2. **Replacement migration:** replace the corresponding legacy labels and migrate workload, Service, PDB, NetworkPolicy, and affinity selectors as a Chart 2.0 breaking change. My preference is the additive option. It gives tools the standard labels without changing immutable workload selectors or existing user queries. The implementation plan would be: - centralize the standard metadata and pod-label fragments, with label-specific 63-character handling and `+` to `_` normalization for `helm.sh/chart`; - apply the five issue-specified labels to all chart-owned object metadata, and the applicable part-of/component/instance labels to generated pod templates and `chart/files/pod-template-file.kubernetes-helm-yaml`; - keep names/components explicit for Airflow, Redis, PgBouncer, StatsD, and OTel resources, and leave the external `app: keda-operator` selector untouched; - preserve existing user-label precedence and coordinate the merge semantics with #70205; - add exhaustive rendered-object, job-template, KubernetesExecutor pod-template, long-name, normalization, selector-preservation, and override-precedence tests. I have completed the current resource/selector inventory and have a clean baseline of 658 passing `airflow_aux` Helm tests. Is the additive direction welcome, and should implementation be based after #70205 lands? --- Drafted-by: Codex (GPT-5); reviewed by @mihirduvedi before posting -- 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]
