jtp
November 29, 2023, 9:13am
1
Starting this discussion to get an idea if such tool already exists, or if there is an issue about it somewhere already.
It would be great if the JupyterHub admins could have a UI to pre-build a set of images to make them available to users of a JupyterHub.
For reference there is already a plugin for The Littlest JupyterHub (TLJH) that offers a way to build images:
But this plugin is for TLJH, and the images are built on the server where TLJH is deployed, with repo2docker.
The idea would be to have something similar, but for a JupyterHub deployed via ZTJH. With the UI, admin users could create environments from repositories just like with BinderHub. But they could also delete them or change a few other options if needed such as memory and CPU limits. Technically this could be implemented as a JupyterHub service like BinderHub.
Then users of the JupyterHub could choose the image they want via the server options:
Currently BinderHub proposes only one UI to build (and launch) a server:
But Iām not sure if something similar to tljh-repo2docker already exists, but for ZTJH, or has already been explored?
Thanks!
1 Like
manics
November 29, 2023, 12:00pm
2
BinderHub recently had an API-mode added
jupyterhub:main ā consideRatio:opt-out-of-launch
opened 08:05AM - 24 Mar 23 UTC
(PR written and made by @GeorgianaElena, it was just initialized by @consideRatiā¦ o to get a branch to reference)
This PR adds a feature that offers the option of an API only mode, and in this mode, it allows opting-out of launching directly after build.
It adds:
- [x] a traitlet called `enable_api_only_node` that defaults to False to preserve existing default behavior. When enabled, there will be no UI, with the only registered endpoints being:
- `/metrics`
- `/versions`
- `/build`
- `/health`
- `/_config`
- `/*` -> shows a custom 404 page
- [x] a query parameter called `build_only` to be passed to individual requests to enable the build only **only** when `enable_api_only_node` is True
```mermaid
flowchart LR
subgraph API only mode enabled
direction TB
id1{{false}}
id2{{false}}
id3{{false}}
id4{{true}}
id5{{true}}
id6{{true}}
end
subgraph `build_only` query param
direction TB
id1 ---|and|id11{{missing}}
id2 ---|and|id12{{false}}
id3 ---|and|id13{{true}}
id4 ---|and|id14{{missing}}
id5 ---|and|id15{{false}}
id6 ---|and|id16{{true}}
end
subgraph Outcome
direction TB
id11 ==> id21{{OK, image will be launched after build}}
id12 ==> id22{{OK, image will be launched after build}}
id13 ==> id23{{ERROR, building but not launching is not permitted when API only mode is not enabled}}
id14 ==> id24{{OK, image will be launched after build}}
id15 ==> id25{{OK, image will be launched after build}}
id16 ==> id26{{OK, image will NOT be launched after build}}
end
```
- [x] tests
- [x] for the configuration corner cases that generate errors
- [x] for the actual build only config
It also updates the `auth` tests for consistency to expect a more descriptive pytest request parameter value in order for the app fixture to load the extra auth configuration. This is for consistency with the build only extra config that was added in this PR.
### Todo
- [ ] Document this once there's agreement on naming an evaluation of the the traitlet and query parameter values to come to an outcome.
### Background
This is meant as a building block for the https://github.com/2i2c-org/binderhub-service project. In brief, its positioning itself to be relevant specifically for situations when a binderhub UI is relevant together with a JupyterHub behind authentication and that also provides user home folder storage.
That PR also links to GitHub - 2i2c-org/binderhub-service
1 Like
