Thanks for bringing this up @davidbrochart. Are you able to add this to the agenda for this week's Server meeting?

I view terminals as optional and kernels, well, less so. Some view terminals as a security issue and need to disable their functionality. While the same could be argued about kernels, they are core functionality.

That said, this does move us toward a more composable server as discussed here and here.

This would allow to proxy the kernels service

FWIW, this functionality exists today by configuring a Gateway server (Kernel or Enterprise) using --gateway-url=http://foo.com although the local kernel managers are present (but unused). (On that note, I'd like us to enable the ability to have multiple "kernel services" in play.)

Are you able to add this to the agenda for this week's Server meeting?

Thanks, I just did it.

I started some work in #1106 and https://github.com/davidbrochart/jupyter_server_kernels.

Hey! What are you trying to do... turn jupyter_server into jupyverse? 😉

In all seriousness, this is certainly a road we could go down in Jupyter Server, but would it be better to just switch to jupyverse for a more composable server?

😄

I don't know, it could also make sense to compose a server with parts of jupyter-server and jupyverse.

it could also make sense to compose a server with parts of jupyter-server and jupyverse.

this. ideally, there would be no knowledge of a down-and-dirty http/websocket request/response in a KernelManager, ContentsManager, etc. and the various pieces would have well-typed, async interfaces at the borders, requiring only a light wrapper to work with a tornado or ASGI request.

this paves the way not only for composability between python implementations, but opens the door for swappable pieces that balance extensibility (not everything has to be HasTraits), performance (get that rust/mypyc in there) and portability. Smaller pieces can be ported to the appropriate technology, and then conformance tested/benchmarked against each other by changing a config file.

only slightly further afield: non-emscripten WASM has the potential to play a very compelling role... a large chunk of jupyterlite, @jupyterlab/services, servers, and kernels of different languages could all share the same bytes when executing.

With #1106 and jupyter_server_kernels, a mixed jupyter-server/jupyverse server is already possible, by using jupyter_server_kernels_proxy to proxy fps-kernels.
I did the same thing with terminals, with jupyter_server_terminals_proxy proxying fps-terminals.
So yes, this opens up new possibilities. During the meeting, we talked about some of them:

• a migration path for people wanting to switch to Jupyverse, but still using some jupyter-server extensions that have not been ported to Jupyverse yet.
• kernels hosted on a different machine/port than the server.

This last point is actually quite powerful, because it does for free what we currently do with jupyter-kernel-gateway, and it's also a very simple alternative to kernel provisioners: the server and the kernels don't have to live in the same environment.

it's also a very simple alternative to kernel provisioners

While I agree that jupyter_server_kernels_proxy could serve as a replacement for Juptyer Kernel Gateway, I respectfully disagree that it provides an alternative to kernel provisioners.

Users want their kernels to use a varying amount of Memory, GPUs, etc. in a separate kubernetes pod, while another needs their kernel launched within a Hadoop YARN cluster running as the Spark driver, cannot accomplish those integrations without Kernel Provisioners. Kernel Provisioners abstract the kernel management lifecycle, which is completely unrelated to the server that launches those processes, and are responsible for provisioning those specific environments in which the kernel will run.

The proxied kernel server (however that is accomplished) detaches the end-user's notebook server from its kernel server (which is great), but provisioners take that extra step of moving the kernel resources off of the "kernel server" in a pluggable fashion within today's launch framework.

While I agree that jupyter_server_kernels_proxy could serve as a replacement for Juptyer Kernel Gateway, I respectfully disagree that it provides an alternative to kernel provisioners.

+1

I don't know, it could also make sense to compose a server with parts of jupyter-server and jupyverse.

We can design for any composable server, my 3 requirements would be:

1. 100% backwards compatibility with the existing server and notebook extensions, included their traits/configs.
2. No lowering performance with unneeded proxy layers (as much as I like software abstraction, I am not in favor of proxy if they can be avoided).
3. As few building blocks as possible, the new Jupyter developer already needs a Jupyterpedia to find its way.

1. 100% backwards compatibility with the existing server and notebook extensions, included their traits/configs.

We'll try our best, but one can't make an omelette without breaking eggs 😄

2. No lowering performance with unneeded proxy layers (as much as I like software abstraction, I am not in favor of proxy if they can be avoided).

The proxies are for demonstration purpose, to show that we can swap a jupyter-server service with a jupyverse service, but of course they are not part of #1106 or https://github.com/davidbrochart/jupyter_server_kernels.

3. As few building blocks as possible, the new Jupyter developer already needs a Jupyterpedia to find its way.

😆

Someone needs to write a documentation site called Jupyterpedia... 😉

Someone needs to write a documentation site called Jupyterpedia... wink

Yep. A heavyweight solution like backstage.io would do this most robustly. It's generally more organized around product rather than projects, and automates a lot of communication (e.g. release notifications, etc) that we're either doing manual today, or just doesn't happen. Actually seems like something NumFocus would be at the right scale to effectively operate, akin to the mastodon discussion on discord.

Lighter-weight, static, and more reproducible for $ANY_ORG: a JupyterLite site with a Zeal/Dash docset viewer and in-browser language servers for "go to definition," etc. Even if it only understand creating json/yaml/toml/kaitaistruct config files up-front, it would still be huge.

And, of course: a backstage that was also a lite site, such that all the underlying data from disparate sources was computable from within the browser would be an insane value-add.

I'd argue we need fewer split-out packages for the server, not more. I don't think making everything a separate package and extension is a positive direction for jupyter-server. It makes almost everything about running, installing, understanding, and debugging more complex. While I think supporting alternate implementations is good, I think the default implementation of almost everything should reside in jupyter-server.

Is there a chance we could revert the extraction of jupyer-server-terminals? It's not true that we need to remove these packages to make them overrideable (already true for KernelManager, ContentsManager, etc.). It seems like it would be quite a bit better and simpler to keep the default implementations in the base server package, rather than breaking it into plugins with circular dependencies on the server, indicating that they aren't really separate at all.

I think the extraction of terminals was for a security reason, to give a strong(er) guarantee that users cannot do arbitrary operations on the backend. It feels safer if the backend doesn't even have the package installed to launch a terminal, rather than disabling terminals in a config file, with the possibility to forget to do it.

I'd argue we need fewer split-out packages for the server, not more.

I agree with the sentiment in general. I agree with Min that we shouldn't extract out the kernels API into a separate plugin in jupyter_server.

Is there a chance we could revert the extraction of jupyer-server-terminals? It's not true that we need to remove these packages to make them overrideable (already true for KernelManager, ContentsManager, etc.).

I do think terminals is a special case here. The goal wasn't to make them just overrideable; rather, it was to make it possible not to register their REST/Websocket handlers with the server at all. Making them a server extension enables deployers to opt out of exposing the terminal endpoints. The general consensus at the time is that, in the long run, we shouldn't ship terminals by default with Jupyter Server.

circular dependencies on the server, indicating that they aren't really separate at all.

The circular dependency was meant to be a temporary transition period in Jupyter Server 2.0. In 3.x, we wouldn't have jupyter_server_terminals listed as a hard dependency of Jupyter Server at all. This would truly be a separate plugin/extension that folks (and clients like Lab) could optionally require.