You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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?
The text was updated successfully, but these errors were encountered:
I need to remap the key of a secret. My kubernetes cluster has a service for provisioning/owning credentials used to access a postgres instance. These are my current set of keys:
but quickwit expects QW_METASTORE_URI not POSTGRES_URL, hence I need to remap the key from the secret I do not control the ENV var expected by the metastore. I need something like this:
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?
The text was updated successfully, but these errors were encountered: