Relocate BinderHub specific config nested to jupyterhub.hub.services.binder

Bug description

Binderhub makes use of jupyterhub.hub.services.binder.oauth_no_confirm and some more. I consider it a bad practice to locate configuration that is specific to the BinderHub Helm chart nested within the configuration options of its dependent Helm charts. I’ll provide three motivations:

1. Z2JH has introduced schema validation that helps users catch errors whenever they pass config to the chart that isn’t recognized by the chart. This has been very helpful and catched a lot of issues already, even in binderhub and mybinder.org-deploy which we maintain - for example config that was passed and ignored.

   For this helms schema validation to work, it must either accept or reject unrecognized config like this, there is no middle ground.

   The reason this fails in 1.1.0 but didn’t in 1.0.0 is because the schema wasn’t as rigorous as it is in 1.1.0, which I consider to be a feature now of 1.1.0 rather than something we want to revert.

2. By BinderHub locating config passed under jupyterhub, it strongly indicates that that config relates to that Helm chart. But, in this case it doesn’t. That makes the configuration hard to understand and think about.

3. With Z2JH 1.1.0 as a dependency of BinderHub, I can make the need to configure jupyterhub.hub.services.binder with an explicit API token optional. When it becomes optional, users won’t need to configure anything under jupyterhub.hub.services.binder, and for them to setup something specific there becomes even weirder.

   • https://github.com/jupyterhub/zero-to-jupyterhub-k8s/pull/2312
   • #1337

Due to the above motivations, I suggest we relocate the configuration - that we make a breaking change. I have not come up with a suggestion as to where though, but it should not be nested under jupyterhub.

This is the validation error we get with the 1.1.0 schema of Z2JH.

Error: values don't meet the specifications of the schema(s) in the following chart(s):
jupyterhub:
- hub.services.binder: Additional property oauth_client_id is not allowed
- hub.services.binder: Additional property oauth_no_confirm is not allowed
- hub.services.binder: Additional property oauth_redirect_uri is not allowed

How to reproduce

Run the tests with JupyterHub 1.1.0 as a dependency, see #1340’s failures.

Suggested solution

To relocate the config outside the jupyterhub helm chart’s config.

[consideRatio]

Ahhh okay, looking closer at this now with @betatim’s reference to the service.py file in jupyterhub, I see that there are loads of configuration that wasn’t listed in the documentation but possible. If z2jh would update its schema for everything of that it would be silly duplication of config etc.

I’m feeling very confident that the right thing to do is to close this issue and let additional properties on hub.services be allowed than those defined in the z2jh schema.

Thanks @betatim and @manics! I’ll submit a PR to z2jh and want to cut 1.1.1 with it merged.

[manics]

I think of schema validation as like linting and code formatting- if you’re starting from scratch it makes sense to be as strict as possible and enforce it, but if you’re adding it to an existing repo there’s a balance between something that’s completely clean, and something that minimises breaking changes for others.

I don’t have enough information to say whether the breaking change is justified yet. As pointed out by @betatim a property is referenced in JupyterHub- how does JupyterHub anticipate this will be used by services? Ignore what BinderHub does, we want the schema to work for other JupyterHub services too- if it’s irrelevant should we remove it from JupyterHub since we’ve got v2 on the way in which case a corresponding breaking change here sounds justified.

What do you think of making a non-breaking PR that adds the current config values to the schema for services (or allows arbitrary additional keys), and if we decide a breaking change is justified make that in a separate PR later?