notebook_kernel_gateway

Jupyter Notebook use of Kernel Gateway

Do we want to enable Jupyter notebooks to launch remote kernels (on a host that is different from the notebook server)?

See https://github.com/jupyter-incubator/proposals/blob/master/kernel_gateway/proposal.md#use-case-3-notebook-authoring-separated-from-kernelcompute-clusters for details about this use case.

1. No. Stick with the status quo. Run the full Jupyter notebook server to get a kernel.

   • Pro: No code changes required.
   • Pro: Notebook content and data files are co-located, e.g., !ls gives you listing of where the notebook is running.
   • Con: Sessions and kernels remain coupled, e.g., ask for a session (/api/sessions), get a kernel (/api/kernels) too?

2. (Pure JS option) Yes. Enable remote kernels. The frontside JavaScript talks directly to a kernel gateway for Websocket and kernel REST APIs, and to the notebook server for all other REST APIs (e.g., content, sessions).

   • Pro: Keeps server-side handler code ZMQ specific
   • Pro: Further decouples notebook frontend from kernel provider part of the backend
   • Con: Kernel API (Websocket and REST) connections are cross-domain. Disable CORS on Websocket connection in kernel gateway.
   • Con: Websocket can't use HTTP headers for token-based auth to kernel gateway. Kernel gateway generates short-lived tokens to be included in the URL as query parameters upon Websocket connection to kernel channels endpoint.
   • Requires:
     • Changes in the JS to make kernel REST calls to kernel gateway
     • Changes in the JS to make kernel websocket calls to kernel gateway
     • Changes in the Python notebook server code to decouple sessions from kernels (e.g., startSession should not create a kernel, JS does that; queries for running kernels never happen on the Python-side, always the JS)
     • A sane security story for having browser-side JS send auth tokens to the kernel gateway

3. (Pure proxy option) Yes. Enable remote kernels. The frontside JavaScript talks to the notebook server for all Websocket and REST APIs, and notebook server proxies kernel traffic to kernel gateway.

   • Pro: Avoid cross-domain/CORS mess to kernel APIs.
   • Pro: Notebook server can use tokens in headers to authenticate to kernel gateway.
   • Con: New websocket proxy handlers do not plug in easily
   • Requires:
     • New RemoteKernelManager that proxies all REST API calls to configured kernel gateway
     • New WebSocketHandler replacements for ZMQHandler that proxies all websocket connections to configured kernel gateway
     • Ability to configure the websocket handler as a replacement without hard-coding the replacement

4. (Hybrid option). See the mess that is https://github.com/jtyberg/notebook/tree/remote_kernels