Allowing users to supply an existing configmap to source env vars from via envFrom is more flexible than env because it allows potential templating within the supplemental env vars.
One use case for this is configuring the enterprise section of vector config, which involves supplying sensitive values API and app keys. I did this using env vars, and added this to my templated configmap for vector.existingConfigMaps:
{{- if .Values.vector.ddObservabilityPipelinesEnabled }}
enterprise:
api_key: ${DATADOG_OBS_PIPELINE_API_KEY}
application_key: ${DATADOG_OBS_PIPELINE_APP_KEY}
configuration_key: ${DATADOG_OBS_PIPELINE_CONFIG_KEY}
{{- end }}
but since I can only define those env vars in env currently, they always have to be defined, regardless of whether .Values.vector.ddObservabilityPipelinesEnabled is true in my values.
Allowing users to supply an existing configmap to source env vars from via
envFrom
is more flexible thanenv
because it allows potential templating within the supplemental env vars.One use case for this is configuring the
enterprise
section of vector config, which involves supplying sensitive values API and app keys. I did this using env vars, and added this to my templated configmap forvector.existingConfigMaps
:but since I can only define those env vars in
env
currently, they always have to be defined, regardless of whether.Values.vector.ddObservabilityPipelinesEnabled
is true in my values.Example using
envFrom
: https://github.com/DataDog/helm-charts/blob/main/charts/datadog/values.yaml#L311-L317