Unable to connect kernel about enterprise_gateway HOT 6 OPEN

Could be this?

from enterprise_gateway.

Thank you for opening your first issue in this project! Engagement like this is essential for open source projects! 🤗

If you haven't done so already, check out Jupyter's Code of Conduct. Also, please try to follow the issue template as it helps other other community members to contribute more effectively.

You can meet the other Jovyans by joining our Discourse forum. There is also an intro thread there where you can stop by and say Hi! 👋

Welcome to the Jupyter community! 🎉

from enterprise_gateway.

Correct. EG doesn't support jupyter_client 7 or higher, nor does it support jupyter_server 2 or higher.

If you must use server >= 2 and client >= 7 you may want to explore using gateway_provisioners.

If you need your "kernel server" separated from your notebook server, you could deploy kernel gateway with gateway provisioners to get similar functionality. That said, EG should be usable so long as your python environments are properly configured.

from enterprise_gateway.

@kevin-bates and @lresende - Thank you for your information. Below is my setup

1. ven-gw - virtual environment for JEG (3.2.2) and configured with a ipython kernel using pip

ipykernel==6.25.2
ipython==8.15.0
jupyter-client==6.1.12
jupyter-server==1.24.0
jupyter_core==5.3.1
jupyter_enterprise_gateway==3.2.2
jupyterlab-pygments==0.2.2
tornado==6.3.3
pyzmq==24.0.1

2. venv-nb - a virtual environment of jupyter-server & lab

Are you saying that I should use the same versions of jupyter-server and jupyter_client as JEG pinned to? i.e 6.1.12 and 1.24.0. Please, clarify it? If possibel, please share requirements.txt file?

Yes, I tried to use JEG on k8s (AWS-EKS) and Jupyter-server/lab from the laptop/EC2 box but I ran into the same above issues.

[I 2023-09-23 11:49:18.217 ServerApp] Connecting to kernel 448500a4-f6a7-437e-9cac-ea134712f108.
[I 2023-09-23 11:49:18.217 ServerApp] Connecting to ws://127.0.0.1:8888/api/kernels/448500a4-f6a7-437e-9cac-ea134712f108/channels
[W 2023-09-23 11:49:19.051 ServerApp] Lost connection to Gateway: 448500a4-f6a7-437e-9cac-ea134712f108
[I 2023-09-23 11:49:19.051 ServerApp] Attempting to re-establish the connection to Gateway in 1.49 secs (1/5): 448500a4-f6a7-437e-9cac-ea134712f108

I will test your suggestions and keep posted. Thanks again for your help.

from enterprise_gateway.

I was able to make it work using JupyterLab==3.6.5 with jupyter-client==6.1.12 and jupyter-server==1.24.0 same as JEG 3.2.2. Below is the details configuration.

jupyter-client==6.1.12
jupyter-events==0.7.0
jupyter-lsp==2.2.0
jupyter-server==1.24.0
jupyter-telemetry==0.1.0
jupyter-ydoc==0.2.5
jupyter_core==5.3.1
jupyter_server_fileid==0.9.0
jupyter_server_ydoc==0.8.0
jupyterhub==4.0.2
jupyterlab==3.6.5
jupyterlab-pygments==0.2.2
jupyterlab_server==2.25.0

Next, I will try suggested using kernel gateway with gateway provisioners. Is there an ETA for JEG supports kernel provisioners?

from enterprise_gateway.

Is there an ETA for JEG supports kernel provisioners?

Not really (unfortunately), unless someone wants to take that on. Although not required, it would be good to first move the base Jupyter Server to 2.0 prior to removing the process-proxies, but given the authorization hurdles encountered in a similar exercise in JKG, it might be better treat the two tasks independently. (Although if the goal is to have a combined Python env for both server and EG, we'd need JS 2.x. I don't view the combined envs to be a requirement since the whole purpose of EG is to separate the compute (kernels) from the user's desktop - and you can achieve that today using JKG and GatewayProvisioners.)

from enterprise_gateway.