[velero] Allow to define resource requests/limits for the containers in the upgrade/cleanup job #305
Conversation
…rs in the upgrade/cleanup job. Signed-off-by: Daniel Simionato <[email protected]>
Signed-off-by: Daniel Simionato <[email protected]>
| @@ -53,6 +53,10 @@ spec: | |||
| kubectl delete volumesnapshotlocation --all; | |||
| kubectl delete podvolumerestore --all; | |||
| kubectl delete crd -l app.kubernetes.io/name=velero; | |||
| {{- with .Values.kubectl.resources }} | |||
There was a problem hiding this comment.
Should these additions be put behind a conditional so that empty "resources" fields aren't added? I'm not 100% sure that it matters, but that way there's no change in yaml for cases where the optional resources aren't specified:
{{- if .Values.kubectl.resources }}
There was a problem hiding this comment.
Hi,
thanks for the review.
I had the same concern but testing with helm template if resources is empty (either resources: {} like in values.yaml or simply resources:) nothing gets included in the final manifest. Basically, if there's something defined it gets converted in yaml and indented with 12 spaces; if there's nothing, nothing gets added as expected.
The same style of inclusion is used freely in the chart ( e.g. for the resources of the main deployment here
, the same goes for nodeSelector,affinity, tolerations, etc.).
There was a problem hiding this comment.
I prefer the with syntax personally.
This PR allows to define resource requests and limits for the containers in the upgrade and cleanup jobs.
This is necessary in kubernetes clusters where an admission controller prevents the creation of pods without proper resource requests and limits.
Checklist
[velero])