Allow resource limits and requests to be over-riden for clusterBootstrapController
#3575
Conversation
…otstrapController
There was a problem hiding this comment.
I'm ok with this, but I think it can be better.
I'd prefer if it was just resources.limits: {} and resources.requests: {} which would let the container use the defaults?
It would still be easy enough to configure the pod via the values?
This would then allow it to be controlled via a LimitRange too?
For clarity, I'm ok with merging it, the fact that it can be better doesn't mean it should be. |
Yes, that's fair enough - my aim with this change was to persist the previous behaviour, so that there would be a seamless change for anyone upgrading, without having to set the values themselves. |
What changed?
This is to address OOM issues seen by Hitachi in the following interlock ticket: https://github.com/weaveworks/weave-gitops-interlock/issues/592
Why was this change made?
The current limits and requests are quite low, and are hard coded - they cannot be easily overriden, so allowing these values to be exposed for configuration via Helm values.
How was this change implemented?
Set new default values for the Helm Chart in
values.yaml, and configured the values in the deployment based on these values.How did you validate the change?
Build a new helm chart release, and set the values in the release to anything other than the new defaults, and make sure a provisioned implementation of the chart provisions these overrides.
Integration tests -- what is covered, what cannot be covered;
or, explain why there are no new tests
Unit tests -- what is covered, what cannot be covered; are
there tests that fail without the change?
Other follow ups