[helm/v2-alpha] missing tolerations, affinity and nodeSelector parameters

[robinlioret]

What do you want to happen?

The generated dist/chart/templates/manager/manager.yaml file for the Deployment of the operator is currently not exposing the tolerations, nodeSelector nor affinity options. Which could be required in certain deployment cases.

The plugin should generate something like this:

# dist/chart/templates/manager/manager.yaml
apiVersion: apps/v1
kind: Deployment
# ...
spec:
    # ...
    template:
        # ...
        spec:
            {{- with .Values.manager.tolerations }}
            tolerations: {{ toYaml . | nindent 16 }}
            {{- end }}
            {{- with .Values.manager.nodeSelector }}
            nodeSelector: {{ toYaml . | nindent 16 }}
            {{- end }}
            {{- with .Values.manager.affinity }}
            affinity: {{ toYaml . | nindent 16 }}
            {{- end }}
            containers:
             # ...

And expose it in the default values file:

# dist/chart/values.yaml

# Configure the controller manager deployment
manager:
  # ...

  # Pods tolerations
  tolerations: []

  # Pods node selection
  nodeSelector: {}

  # Pod affinity
  affinity: {}

Note: I'm aware that this is kind of a duplicate of #4912 but since the previous issue was closed, i'm opening a new one.

Extra Labels

No response

[camilamacedo86]

Thanks for the proposal.

We don’t plan to expose tolerations, nodeSelector, or affinity as Helm
values in the generated chart.

The Helm chart generated by Kubebuilder is only meant to package and
distribute a project. It should not define or change what the project
supports.

Scheduling options like these are cluster and platform policy decisions.
Allowing them as Helm values would let end users run the controller on nodes,
OSes, or architectures that the project authors did not build or test for.
This would break the project’s support guarantees and may result in
non-working deployments.

If a project requires specific scheduling rules, those must be defined and
owned by the project itself (for example in the manifests or via kustomize),
not provided as configurable Helm values.

We should only have in the Helm values what make sense be changed by who consumes the project.
Maintainers should properly configure things like that via kustomize files so that when they package their solution with Helm those should endup in the HelmChart manifest but not exposed in the values.

So, I would like to close this one as not planned.
Please, let me know if you understand the reasons and wdyt.