[karunpoudel]

The webserver specific labels are missing from webserver deployment labels. Other objects like webserver service, hpa etc includes this label but not just deployment.

Use case:
Our kubernetes infrastructure has Kong mesh hooks that is configured by deployment labels. Currently there is no way to set this up just for webserver without applying same label in other airflow components

---

^ Add meaningful description above
Read the Pull Request Guidelines for more information.
In case of fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
In case of a new dependency, check compliance with the ASF 3rd Party License Policy.
In case of backwards incompatible changes please leave a note in a newsfragment file, named {pr_number}.significant.rst or {issue_number}.significant.rst, in airflow-core/newsfragments.

[Miretpl]

Nice catch! Could you add a test case for it too?

[romsharon98]

I see that here we do take the webserver lables, in all other airflow deployments (scheduler, dag-processor..) we have this pattern that under metadata: labels we take the general labels and under spec:template:metadata:labels we take the merge labels.

[karunpoudel]

I see that here we do take the webserver lables, in all other airflow deployments (scheduler, dag-processor..) we have this pattern that under metadata: labels we take the general labels and under spec:template:metadata:labels we take the merge labels.

Those merged labels are applied only to pods, not to deployments

[romsharon98]

so we would like to add those labels also to the other airflow components?

[Miretpl]

I would say - yes, we want, but the question is how. Looking at the Helm Chart and different settings like annotations, there is a clear distinction based on where the values are applied (annotations, e.g. Deployment level and podAnnotations for pod level), but there is no such logic in terms of labels, and maybe it should be?

So, basically, add podLabels section to each component, and these labels would be applied on the pod level, and the labels will be added on, e.g. Deployment level. When podLabels would be undefined, the values could go to the pod level from labels and not to the Deployment level to ensure backward compatibility.

WDYT?

[romsharon98]

I would say - yes, we want, but the question is how. Looking at the Helm Chart and different settings like annotations, there is a clear distinction based on where the values are applied (annotations, e.g. Deployment level and podAnnotations for pod level), but there is no such logic in terms of labels, and maybe it should be?

So, basically, add podLabels section to each component, and these labels would be applied on the pod level, and the labels will be added on, e.g. Deployment level. When podLabels would be undefined, the values could go to the pod level from labels and not to the Deployment level to ensure backward compatibility.

WDYT?

Sounds good to me but lets wait for another opinion.
@potiuk @eladkal @jedcunningham 🙌

[potiuk]

Sure - needs test update though. I rebased it to re-run with latest main

[jscheffl]

For me it is okay to apply this where needed and only to webserver for the moment - but if you apply it wo webserver, then please do the same in api-server as well as webserver will be gone once we drop Airflow 2.x support.

[Miretpl]

@jscheffl apply it in current form (webserver.labels on the metadata.labels and metadata.spec.template.metadata.labels level) or in the proposed form above with separation for webserver.labels and webserver.podLabels?

[karunpoudel]

I don't have immediate need for this so we can keep this open

[Miretpl]

Hi @jscheffl, would you have a moment to take a look at my message above?

[jscheffl]

@jscheffl apply it in current form (webserver.labels on the metadata.labels and metadata.spec.template.metadata.labels level) or in the proposed form above with separation for webserver.labels and webserver.podLabels?

Had a look but did not have an answer. No strong opinion but I assume labels are used more often than padLabels?

My point was about apiServer vs webserver.

[Miretpl]

Had a look but did not have an answer. No strong opinion but I assume labels are used more often than padLabels?

Currently, there are no podLabels in the chart. It would require adding a new section (in terms of the whole chart) and changing the logic of how Helm Chart works if podLabels were defined.

My point was about apiServer vs webserver.

I agree that change should be in both components (if it is to be done for any).

[Miretpl]

Hi @karunpoudel, so I guess (looking at the no update here), you can go with the way which you will prefer regarding podLabels or not. Just remember to implement the change for both webserver and api-server components

[potiuk]

This pull request has had no activity from the author for over 4 weeks. We are converting it to draft to keep the review queue manageable.

@karunpoudel, please mark this PR as ready for review when you are ready to continue working on it. Thank you for your contribution!

[potiuk]

@karunpoudel This draft PR has had no activity for 3 weeks. Closing to keep the queue clean.

You are welcome to reopen and continue when you're ready. If you'd like to pick it back up, please rebase onto the current main branch first.

---

Note: This comment was drafted by an AI-assisted triage tool and may contain mistakes. Once you have addressed the points above, an Apache Airflow maintainer — a real person — will take the next look at your PR. We use this two-stage triage process so that our maintainers' limited time is spent where it matters most: the conversation with you.