Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Building application on top of enterprise gateway #840

Closed
xinbinhuang opened this issue Jul 21, 2020 · 5 comments
Closed

Building application on top of enterprise gateway #840

xinbinhuang opened this issue Jul 21, 2020 · 5 comments
Labels

Comments

@xinbinhuang
Copy link

Help us improve the Jupyter Enterprise Gateway project by reporting issues
or asking questions.

Description

Hi team,

Thank you so much for creating so many good tools on the Jupyter ecosystem.

I am trying to build some web application (something similar to JupyterHub) based on the Jupyter messaging protocol and Jupyter Enterprise Gateway. I wonder how should I interact with the gateway properly? Should it be a socket connection or RESTful request/response style?

I also notice the project jupyter_server, it seems like a good starting point?

I have tried to interact with the local kernel using the KernelManager and KernelClient and read through the system architecture for EG. What's the difference between MappingKernelManager and KernelManager. And if there is a counterpart of KernelClient that can used to talk to the Remote(Mapping)KernelManager.

Thanks for your time reading my questions and your responses are much appreciated!

Cheers
Bin

Environment

  • Platform: Kubernetes
  • Others [e.g. Jupyter Server 5.7, JupyterHub 1.0, etc]
@kevin-bates
Copy link
Member

Hi @xinbinhuang - thank you for your interest.

I am trying to build some web application (something similar to JupyterHub) based on the Jupyter messaging protocol and Jupyter Enterprise Gateway. I wonder how should I interact with the gateway properly? Should it be a socket connection or RESTful request/response style?

The analogous application dedicated solely to EG would be a Kernel As A Service model. However, if your users are expecting interactions with notebooks, then you'd just deploy EG as a kernel server behind the corresponding Notebook server using Notebook's --gateway-url option.

Since I believe you are indeed talking about a KAAS model, the interaction with EG would be two-fold. You'd use the REST API to perform kernel lifecycle management (start, interrupt, restart, shutdown, list) and a WebSocket for communication with the kernel (code execution). I would recommend taking a look at the GatewayClient we use for our integration testing. It provides basic support for each of these operations and, should you find it useful, would be ideal to promote (i.e., enhance) to something more than the experimental tool that it is.

I also notice the project jupyter_server, it seems like a good starting point?

juptyer_server is essentially the notebook server project w/o a frontend. It is the future core server project and we do anticipate it supporting things like multi-user capabilities, authorization, telemetry, etc. that notebook server does not. At some point, we will likely want to have an offering of EG that depends on or extends jupyter_server but that doesn't exist at the moment as we're still trying to determine what server will support in itself. Since jupyter_server is essentially notebook, you can use its --gateway-url option to proxy its kernel management to EG, however.

To interact with kernels directly, you'd likely use jupyter_client, where KernelManager and KernelClient reside. (Note that the KernelClient in the aforementioned GatewayClient module is unrelated and should be renamed.) The KernelClient in jupyter_client is essentially agnostic about its associated KernelManager instance since talking to a remote kernel via KernelClient is really no different than talking to a local kernel. Only the lifecycle management (provided by the corresponding KernelManager instance) varies when it comes to local and remote operations.

What's the difference between MappingKernelManager and KernelManager.

Good question. MappingKernelManager is a subclass of MultiKernelManager and purely manages a list of KernelManager instances. All operations of KernelManager are surfaced to MultiKernelManager (and its subclasses) but all take a kernel_id as a parameter so that the appropriate KernelManager instance can be acted upon. MappingKernelManager in Notebook (and Jupyter Server) also provides some activity monitoring and this is where kernel culling is implemented, but, generally speaking, the "mapping kernel managers" just enable the ability to act on KernelManager instances. Wrt EG, RemoteMappingKernelManager is where we hook some HA/DR functionality (experimental).

If you're really just driving at a lower level interaction with a KernelManager but wish to use RemoteKernelManager, you might be interested in this recent PR in which RemoteKernelManager can be used independently of EG itself.

I'm sorry for the scattered response, but I really couldn't determine at what level you're are interested. I hope you find this information helpful and please feel free to continue the conversation.

@xinbinhuang
Copy link
Author

@kevin-bates Thank you so much for the detailed reply! It pretty much answer all my questions. And you are correct, Kernel As A Service model is my target. Our current application utilize the old jupyter protocol (before jupyter is separated from IPython), and now it comes to a point that impacts scalability, performance and maintenance. We are trying to upgrade and potentially re-architect the system.

Sorry about my late reply, I was pulled away by other priorities in my job so I did not have the time to dig deeper into this yet. But I will definitely come back to this later on when my plate if less full. At the meantime, I am thinking if the project have some good first issue for PR, so I can get more familiar with the system. When later on I do come back to it, I can quickly build out the application.

@kevin-bates
Copy link
Member

At the meantime, I am thinking if the project have some good first issue for PR, so I can get more familiar with the system.

Thank you @xinbinhuang. I think adding typing hints would be a great way to get familiar with EG, so I've created a (large) umbrella issue (#847) that points to various sub-issues for adding typing hints. Go ahead and grab one when you can.

@xinbinhuang
Copy link
Author

At the meantime, I am thinking if the project have some good first issue for PR, so I can get more familiar with the system.

Thank you @xinbinhuang. I think adding typing hints would be a great way to get familiar with EG, so I've created a (large) umbrella issue (#847) that points to various sub-issues for adding typing hints. Go ahead and grab one when you can.

Thanks you! I will definitely take a look into it!

@kevin-bates
Copy link
Member

I'm going to close this issue. If you feel your question was not adequately addressed, please feel free to re-open it at that time.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants