chart: api-server Deployment always includes spec.replicas when HPA is enabled#63187
Conversation
|
Congratulations on your first Pull Request and welcome to the Apache Airflow community! If you have any issues or are unsure about any anything please check our Contributors' Guide (https://github.com/apache/airflow/blob/main/contributing-docs/README.rst)
|
jscheffl
left a comment
There was a problem hiding this comment.
Let's have CI green, then LGTM in my view.
0b97c47 to
665c6be
Compare
f636a15 to
61e4c80
Compare
Miretpl
left a comment
There was a problem hiding this comment.
Generally - looks good.
I checked how it is handled in e.g. workers, and basically it is handled automatically if on e.g. hpa.enabled flag to add/remove replicas field. The same goes for webserver and triggerer, which have HPA/KEDA implemented.
Could we make the behaviour consistent? (below example from webserver):
{{- if not .Values.webserver.hpa.enabled }}
replicas: {{ .Values.webserver.replicas }}
{{- end}}75fcca8 to
0dad3b4
Compare
0dad3b4 to
d1e9c56
Compare
|
Awesome work, congrats on your first merged pull request! You are invited to check our Issue Tracker for additional contributions. |
When
apiServer.hpa.enabled: true, the Deployment manifest still containsspec.replicas: 1.HPA modifies this field at runtime, causing GitOps tooling to continuously detect a diff between
the desired state in Git and the live cluster state — a permanent out-of-sync condition.
Fix: wrap
spec.replicaswith akindIs "invalid"guard so the field is omitted entirely whenapiServer.replicasis set to~(null), letting HPA be the sole owner of the replica count.closes: #63186
Was generative AI tooling used to co-author this PR?
Generated-by: Claude Sonnet 4.5 (Sisyphus / OhMyOpenCode) following the guidelines