Support/document singleuser profiles with entirely different frontends

[TiemenSch]

Proposed change

A possibility of including a singleuser profile that leverages the JupyterHub infrastructure (user auth, volume/storage, idle user culling), but runs an entirely different frontend alongside only some Hub service essentials (if any). I.e. even without a Jupyter frontend installed.

Alternative options

I previously have fallen back to running services in parallel and adding a button to the JupyterLab launcher to redirect or selecting a different startup URL leveraging a ServerProxy, but I would like to keep things a bit leaner where I can for specific user sessions.

Who would use this feature?

Users with vastly different frontends or cloud IDE's that would work around the same user data as their Jupyter Notebook analyses.

The Z2JH infrastructure offers great and simple to use multi-tentancy for containerized applications, but hosting any frontend application with a mounted and persisted directory would enable highly flexible workflows.

Any user-essentials or requirements to a valid singleuser image?

If I were to depart from a blank nginx image (or something similar), what would I need to add for it to work as a singleuser image with JupyterHub's:

• user authentication
• volume
• culling (session timeout)
• (insert other essentials here)

Does it needs to support specific endpoints? Should it be wrapped in a jupyter_server-esque wrapper? Is it just a matter of clever KubeSpawner config and some reverse proxy work in the container image? I can't seem to find this in the documentation.

Any answers or pointers would be greatly appreciated!

[minrk]

jhsingle-native-proxy is basically the proxy part of jupyter-server-proxy, but as a standalone proxy instead of running as part of a jupyter-server instance.

I personally really think it makes sense to have an official version of this (whether it's jhsingle-native-proxy or another implementation) that can be setup to run in a sidecar container in the notebook pod, so that we can make truly zero assumptions about what's in the actual user container other than launching something on a port.

user authentication

JupyterHub uses OAuth. Whatever the most appropriate OAuth 2 implementation for your server will work. If your app is Python, HubOAuth class provides some high-level convenience, loading config from the environment variables we set by default, etc., but you don't need to use it. Here's an example of configuring jupyterhub itself to use jupyterhub as a generic oauth provider.

volume

This is not handled inside the container, it is the Spawner that mounts volumes, so nothing should need handling here.

culling (session timeout)

Culling uses a field in JupyterHUb called `last_activity. This is the most complex one. In the simplest case, you can rely on the default configurable-http-proxy's monitoring of network traffic as a measure of idleness. This is very coarse and doesn't make the best decisions:

• lots of 'idle' webapps have heartbeat/polling traffic, which can keep an unused server running
• no way for a disconnected server to indicate that it's not idle (e.g. launch a background job that should be allowed to finish)
• not all proxies collect this information (notably: all of them except the default CHP), so you'll completely lose culling behavior if you rely on it and things move to another proxy (which we've been trying to do for some time)

As a result, JupyterHub also has an API for servers to POST last_activity. Then applications can use their own internal measurements to decide whether it's idle or not, and post updates every five minutes or so (doesn't need to be often, just significantly shorter than the idle timeout).

[TiemenSch]

so that we can make truly zero assumptions about what's in the actual user container other than launching something on a port

That would be awesome! I've been struggling on and off with getting this to work "elegantly" and that would be a great piece of the puzzle.

culling

I was afraid this would be the culprit as it requires (occasional) communication between the hub and singleuser pod/container.

Perhaps both routes could be supported using an environment variable pointing to an endpoint on the frontend container that returns a timestamp corresponding to the most recent activity (for others to implement)?

Or is there a way to obtain the freshness of the OAuth state on the Hub side? That might not be suitable for cases where containers do long running simulations based on occasional user input, but could serve as an alternative for frontends that require "active usage".

In general: is there more communication involved between the hub and singleuser application?