Is there a facility for dynamically adding services to the Hub?

JupyterHub
1

The Hub can be made aware of pre-spawned services by using the c.JupyterHub.services setting in the configuration file. For example,


c.JupyterHub.services = [
    {
        'name': SERVICE_NAME,
        'url': SERVICE_URL,
        'api_token': API_TOKEN
    }
]

However, is it possible to add these dynamically? I tried just appending them to the list, but that didn’t seem to work.

I would like to add them dynamically from a Spawner. I asked a similar question in another thread, but I thought rephrasing it this way may make it more clear what I am trying to do.

Thank you.

2

No, at this point services can only be added by editing configuration files and restarting the hub.

Usually, the answer for launching an additional endpoint as part of a Spawner is jupyter-server-proxy, so it’s within the server that the proxy occurs, rather than telling the Hub about it.

1 Like
3

@minrk We are using JupyterHub as an OAuth provider for external applications which are not managed by JupyterHub. We want to be able to register the OAuth clients dynamically at runtime so now we are manipulating the hub database manually.
Is there any technical constraint that prevents adding the mechanism for registering non-managed services to Hub at runtime?

4

No, only that an API hasn’t been implemented. We only need to handle:

  1. API (and scopes, etc.) for creating/listing/deleting oauth clients. Creating them should be equivalent to defining them in config (all the same inputs), and
  2. reconciling changes via the new API vs changes from config at hub startup time

Point 2 means we need to be careful to reconcile runtime changes from config changes, as discussed for runtime-defined roles. Right now, removing a service from config means removing it from the database. We would need to make sure we can distinguish services registered at runtime from services that came from config, so that we can:

  1. continue to remove services from the db when removed from config
  2. prevent changing services via the API that were registered via config
  3. leave services created at runtime alone during startup

This can be a boolean column in the database, or even a constraint on the client id string (e.g. API-created clients get a prefix that’s illegal otherwise - client IDs created via the API have no need to be user-controlled - they aren’t in any other OAuth provider, I think).

1 Like