[collector] Templating support for extraEnvs/From

[thejoeejoee]

Currently, just part of pod configuration values supports templating (extraVolumes extraVolumeMounts extraContainers initContainers), which is inconsistent.

Would be convenient to have support in other configuration fields, especially extraEnvs, extraEnvsFrom.. it would make sense to template also lifecycleHooks, extraArgs and maybe some others.

[JaredTan95]

hi, The currently supported templating is all implemented based on the actual needs of the community. Maintaining a consistent experience is indeed very important, but can we give an example of a scenario: in what scenarios is extraEnvs and extraEnvsFrom requires templating?

[thejoeejoee]

@JaredTan95 technically the same reasons why extraVolumes are templated.

For example installing otelcol-collector as dependency of the project chart and loading secrets from secret created with dynamic name.

templates/secret.yaml

apiVersion: external-secrets.io/v1
kind: ExternalSecret
metadata:
  name: {{ include "project.fullname" . }}-otelcol
spec:
  refreshInterval: "1m0s"
  secretStoreRef:
    kind: ClusterSecretStore
    name: my-store

  dataFrom:
    - extract:
        key: "project-{{ .Values.instance }}"
        property: "otelcol"

  target:
    name: {{ include "project.fullname" . }}-otelcol

values.yaml

my-project:
  # ... values
  otel_endpoint: >-
    {{ include "project.fullname" . }}-otelcol
    

opentelemetry-collector:
  nameOverride: otelcol

  extraEnvsFrom: |
    - secretRef:
        name: {{ include "project.fullname" . }}-otelcol

With this setup, you can install multiple instances of the same project to same namespace without collisions:

helm install instance-1 ./
helm install instance-2 ./

Without twiddling values likes --set "opentelemetry-collector.extraEnvsFrom.0.secretRef.name=instance-1-otelcol".

[TylerHelmuth]

@thejoeejoee thanks for the details. Feel free to submit PRs that add more tpl support.