Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve extraEnv to manage a non-list value as a workaround to helm config overrides #131

Open
consideRatio opened this issue Jul 12, 2024 · 0 comments

Comments

@consideRatio
Copy link
Member

consideRatio commented Jul 12, 2024

extraEnv in this chart is a list currently where its elements gets rendered under env without additional parsing. The downside of this is that declaring extraEnv from two config files leads to overriding the list instead of appending or replacing individual entries.

Current status

# current config syntax
extraEnv:
  - <k8s native env element, not manipulated by the chart besides applying `tpl`>
  - ...

Current rendering logic:

{{- with .Values.extraEnv }}
{{- tpl (. | toYaml) $ | nindent 12 }}
{{- end }}

jupyterhub chart current status

It supports configuring extraEnv in several ways, which added notable complexity and made it hard to understand what it renders to and how to configure it without reading the configuration reference.

See the Deployment template's env specification, and the referenced chart helper function.

Proposal

  1. To make extraEnv be an object instead of a list (breaking change)
  2. Let the object's key's be ignored, and its values rendered like the list's elements

So in practice, this means to do it like z2jh, but with the differences of:

  • not accepting extraEnv as a list
  • not accepting "basic notation" or "implicit notation" as described in hub.extraEnv
  • rendering extraEnv key's values using tpl
extraEnv:
  <any key name>: <k8s native env element, not manipulated by the chart besides applying `tpl`>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant