helm chart: additional options to add environment variables

[christianjedroCDT]

PR Description

Which issue(s) this PR fixes

We´re using the Agent Helm-Chart and there is currently no good way to get environment variables/secrets into the container.

• .Values.extraEnv is a list which makes it hard to use in pipelines in which those values need to be defined in the values file and also in the pipeline as a list always needs to be defined completely
• .Values.envFrom can already take a secret but does not reload the container if the values change (reloader would be required)

Therefore i´m suggesting to add env & secrets for which users can define key=value pairs which makes usage easier and resolves mentioned issues.

Notes to the Reviewer

PR Checklist

• CHANGELOG.md updated
• Documentation added (in values.yaml)
• Tests updated
• Config converters updated

[CLAassistant]

All committers have signed the CLA.

[rfratto]

Hi, thanks for the PR, and sorry it took so long to get back to you.

In general, I'm worried about adding more than one way of doing something, and we already have four ways of exposing secrets:

1. extraEnv in the values file
2. envFrom in the values file
3. The remote.kubernetes.secret component
4. Mounting the secret as a volume (instead of an environment variable) so you don't need to restart the container when the secret changes.

I think yet another way would have to be extremely justified.

Have you explored all four of those ways already?

[jkroepke]

Hi @rfratto

extraEnv is problematic, since it's and list of objects and lists are not mergable from Helm values point of view.

We would like to pass Username and Password for an upstream Prometheus to the Agent. We are using classical Helm deployment + secret injection via --set .

Additional, we are having an umbrella Chart which bundles Grafana Agent + kube-state-metics + goldpinger together. And we have the problem that we are not able to define defaults values for extraEnv. The whole block gets overridden, if a dev teams wants to changes values.

Using envFrom has the disadvantage that there is no Agent reload, if values inside the linked ConfigMap are changing.

---

A valid alternative would be the mounting option here if the proposal gets rejected.

[christianjedroCDT]

Hi, thanks for the PR, and sorry it took so long to get back to you.
Have you explored all four of those ways already?

Hi @rfratto, thanks for your review. I´ve rebuild our helm chart and it´s now using remote.kubernetes.secretwhich is working fine. Therefore this PR is really not needed.