chore: Normalize how resources are set for each container

[lindhe]

Description

This PR normalizes how we set resources for each container and initContainer, first by standardizing how we include the values in the templates and secondly by resouces to {} by default, aligned with Bitnami's standard.

Here's one example of Bitnami documenting their reasoning for it:

We usually recommend not to specify default resources and to leave this as a conscious choice for the user. This also increases chances charts run on environments with little resources, such as Minikube.

— https://github.com/bitnami/charts/blob/7345c0bb2842b73f299aacd2af37147bd7b714cd/bitnami/nginx/values.yaml#L331-L334

We don't have to follow Bitnami's standard, but I think it's reasonable to do so. Unless we are very confident that a container has some upper/lower bound on its resource utilization, it's probably best to condition the chart user to always set the resources explicitly.

Considering how Kubernetes hide the exact capacity of CPU cores etc., it's pretty much impossible to set resource requests/limits that work the same for everyone. This strategy also reduces the need to make additional changes when updating the chart's default images in the future.

Fixes #109

Checklist

Ticks in all boxes and 🟢 on all GitHub actions status checks are required to merge:

• I'm aware of the code of conduct.
• I've created logical separate commits and followed the commit message format.
• I've added relevant test cases.
• I've added relevant documentation.
• I've marked translation strings.
• I've identified the copyright holder(s) and updated copyright headers for touched files (>15 lines contributions).
• I've NOT included third-party code (copy/pasted source code or new dependencies).
  • If you have added third-party code (copy/pasted or new dependencies), please reach out to an architect on Discord.

Frontend

• I've followed the CSS/JS and React guidelines.
• I've followed the web accessibility guidelines.
• I've followed the user interface guidelines.

Reminder

By using GitHub, you have already agreed to the GitHub’s Terms of Service including that:

1. You license your contribution under the same terms as the current repository’s license.
2. You agree that you have the right to license your contribution under the current repository’s license.

[Copilot]

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

Comments suppressed due to low confidence (1)

charts/invenio/templates/worker-beat-deployment.yaml:91

• Unconditionally rendering an empty resources block may lead to unexpected behavior if Kubernetes does not accept an empty mapping. Consider conditionally rendering the resources block only when the provided value is non-empty.

resources: {{- toYaml .Values.workerBeat.resources | nindent 10 }}

[lindhe]

There may be additional initContainers that I have not considered. But I think those has to be postponed until later, because it's practically impossible to work with initContainers in the chart right now. The chart has to be restructured w.r.t. initContainers before it makes any sense to spend time on them, in my opinion.

[egabancho]

Just to questions:

• Could we comment similarly to the one you linked on the nginx chart? We usually recommend not to specify default resources and to leave this as a conscious...
• Since we are, essentially, removing default values for resources, do you think there is a way to warn users about this change? Other than release notes ☺️

[lindhe]

• Could we comment similarly to the one you linked on the nginx chart? We usually recommend not to specify default resources and to leave this as a conscious...

Excellent suggestion! I'll see to it.

• Since we are, essentially, removing default values for resources, do you think there is a way to warn users about this change? Other than release notes ☺️

Oh yeah, right. That. 🫤 I guess we could add a warning in NOTES.txt that shows up if resources are unset. I don't think I've seen that before, and it might be a bit annoying to maintain over time, but I think that would provide a pretty good help to users. Sounds reasonable?

[lindhe]

@egabancho I've updated the comments now, so I think that's been resolved.

I've also added some logic to NOTES for printing a warning if resources is unset for any of our internal resources (not dependencies; I'm leaving that for Bitnami to implement). Please take a look and see if you like the solution. It turned out to be more complex that I first thought it would be, so maybe I've missed something obvious.

Resulting message looks like this:

[egabancho]

LGTM!