Nesting levels in config.yml file

JupyterHub
1

I’m a little stuck working with the config.yaml from the (excellent!) zero-to-jupyterhub repo.

When I read this in the docs https://zero-to-jupyterhub.readthedocs.io/en/latest/security.html#set-up-automatic-https I’m never clear where in my config this goes.

If I place this at the root level and run helm upgrade ..., the values never show up inside the config maps on GKE where I’m running jupyterhub.

Currently doing a bit of trial-and-error nesting it at different levels and seeing where it shows up:

binderhub:
  [here]

or

binderhub:
  jupyterhub:
    [here]

or

binderhub:
  jupyterhub:
    hub:
      [here]

can anyone give a hint as to how this file gets parsed?

1 Like
2

First, the structure of values.yaml is dictated by the chart being configured. You can see the default jupyterhub values.yaml here which shows you the structure. The documentation for individual values is here.

So if you are deploying just jupyterhub and want to configure the hub, you would have top-level keys such as ‘hub’, ‘singleuser’, ‘auth’, etc., e.g.:

auth:
  type: 'github'

hub:
  resources:
    memory:
      limit: '1G'

Second, when one chart includes another, as is the case with binderhub including the jupyterhub chart, then the included chart’s values.yaml are loaded from a key with the chart’s name, within the parent values:

# binderhub chart config is top-level
registry:
  username: 'minrk'
  password: 'xxx'

# jupyterhub chart config is now under a 'jupyterhub' key
# this key is dictated by the name of the included chart
jupyterhub:
  hub:
    resources:
      memory:
        limit: '1G'

You can see the binderhub values.yaml contains some default overrides for config in the jupyterhub chart.

Finally, if you deploy binderhub itself as a dependency of a local chart, as is done for mybinder.org, you would have binderhub as a top-level key and jupyterhub nested below binderhub:

binderhub:
  registry:
    ...
  jupyterhub:
    hub:
      ...
1 Like
3

I wanted to add some clarification to this. In Helm, nested chart dependencies are managed by using a special file named requirements.yaml. To learn more about using such files, see the related Helm documentation.

To summarize, Helm chart are configured through provided values and have their own default values, but when you have a Helm chart that is utilizing another helm chart, the other helm chart’s values (the sub chart’s values) can be overridden by the parent chart’s values. Binderhub is a parent chart for the jupyterhub Helm chart, and the mybinder.org-deploy repo have made another helm chart that requires the BinderHub helm chart.

4

thanks both ! that’s very helpful. So I should interpret the z2jh docs as telling me what to put inside the binderhub chart?

5

Yepp has a dependency on the z2jh helm chart, so if you deploy a binderhub helm chart you get a z2jh helm chart along with it, and you can configure that in turn by writing to values under jupyterhub.