Right now the .Values.metastore.extraEnv is expected as only literal K/V pairs and does not allow for the pulling in an environment variable from a secret. For me it is important to have the power to remap keys from a secret, I can't just use envFrom because the keys don't match what is expected by quickwit.
I don't think the helm chart should take such a strong opinion on the environment variables, allow the user to write YAML which gets substituted in. Something like:
and now the helm chart can support mapping/remapping ENV vars from literal, configmaps, and secrets. This would be a breaking change -- perhaps we want to add a new config variable while continuing to support the K/V style?
Right now the
.Values.metastore.extraEnv
is expected as only literal K/V pairs and does not allow for the pulling in an environment variable from a secret. For me it is important to have the power to remap keys from a secret, I can't just useenvFrom
because the keys don't match what is expected by quickwit.I don't think the helm chart should take such a strong opinion on the environment variables, allow the user to write YAML which gets substituted in. Something like:
possible values spec:
and then in the metastore-deployment.yaml:
and now the helm chart can support mapping/remapping ENV vars from literal, configmaps, and secrets. This would be a breaking change -- perhaps we want to add a new config variable while continuing to support the K/V style?