Add default selectorLabel to topologySpreadConstraints if not otherwise specified #429
Conversation
If someone defines one or more entries in the `topologySpreadConstraints` list and does not define the `labelSelectors.matchLabels` keys then default values will be added. Most people are likely going to want the default selectorLabels so the spread constraints match what they are deploying with this chart.
bderrly
force-pushed
the
default-topology-constraints
branch
from
076c5ec to
ed379a9
Compare
charts/vector/templates/_pod.tpl
Outdated
| @@ -174,6 +174,13 @@ tolerations: | |||
| {{- end }} | |||
| {{- with .Values.topologySpreadConstraints }} | |||
| topologySpreadConstraints: | |||
| {{- range $_, $entry := . }} | |||
| {{- if not (dig "labelSelectors" "matchLabels" false $entry) }} | |||
| {{- $ls := "labelSelectors:\n matchLabels: {}" | fromYaml }} | |||
There was a problem hiding this comment.
Not very familiar with this, but the \n seems a bit hacky. I wonder if we can do this more cleanly with a dict.
There was a problem hiding this comment.
I agree, it's kind of gross. I just updated this to use the dict function to create the nested dictionary keys.
|
I'm afraid I don't know enough about |
|
Disclaimer: Bear with me as I ramp up in this area. Would this be considered a breaking change? Per https://kubernetes.io/docs/concepts/scheduling-eviction/topology-spread-constraints/ I think this can change pod grouping. |
bderrly
changed the title
|
I think this has the potential to cause a "breaking" change in that it may cause the spread constraint functionality to begin working as intended. That is, if a user has not explicitly defined the selectorLabel field in their values file, then no matching pods will be selected and the spread constraint feature will not function as expected. I tested this behavior on the HEAD of the develop branch using kind (kubernetes version 1.32) and I received the following warning from kubernetes:
The chart installed successfully and the pod is running. With this PR, however, there was no such warning and, presumably, the spread constraint feature will operate as expected. |
If someone defines one or more entries in the
topologySpreadConstraintslist and does not define thelabelSelectors.matchLabelskeys then default values will be added. Most people are likely going to want the default selectorLabels so the spread constraints match what they are deploying with this chart.The alternative to this is to run the configuration in this key through the
tplfunction to allow users the ability to call named templates. Similar to howextraObjectsis handled.