After jupyterlab pod has been starten, impossible to switch image through jupyterhub

[romeokienzler]

Describe the bug One a jupyterlab instance has been created (with a previously selected image), the use is always redirected to that running instance, no chance to re-access jupyterhub to create additional instances, change the instance configuration (e.g. resources or containerimage

To Reproduce Steps to reproduce the behavior:

1. in ODH launch "JupyterHub"
2. create a jupyterlab instance by selecting image, resources, ... in the jupyterhub interface
3. close everything
4. go to step 1 again => jupyterhub interface won't show up, you're directly redirected to the JL instance

Expected behavior Show the JL interface to stop existing instances, allow for changing configs and re-launch..

Environment

• openshift:4.8.31_1546 on IBM Cloud
• ODH operator 1.1.2 stable
• Kubeflow version: build version dev_local (version number can be found at the bottom left corner of the Kubeflow dashboard):
• kfctl version: (use kfctl version):
• Kubernetes platform: openshift
• Kubernetes version: openshift:4.8.31_1546

[LaVLaS]

For steps 3 & 4: Are you closing the browser while the notebook is spawning and when you reconnect, you can't get back to JupyterLab?

[romeokienzler]

Hi @LaVLaS - no - I'm closing the browser tab an if I re-open (by clicking on the direct link or by clicking on the link in the opendatahub application launcher (which is the same) I'm forwarded to the running (and working) instance on JL - so the concern is (while the JL pod is running) there is no way (other then directly in kube/openshift) to destroy that pod and create a new on with a different config (image, resources) ... so you need to wait until it times out that you can start over

[guimou]

Hey Romeo! It's not a bug, it's a feature! More precisely it's how JupyterHub works. Once you launch an image (a pod), it stays there. And JH knows about it, it keeps track on who has launched what. It has to because it acts as the proxy for all interactions between your browser and your notebook pod. It maintains a Routes table to know that when Romeo's browser sends a command to its Pod/Kernel, it has to forward it to the right pod. When you close your tab, it's just that, you close the frontend. But the backend, the Pod where everything happens is still there. And when you reconnect to JupyterHub through another tab, another browser or whatever, JH already knows you have a pod running under your name and connects you to it directly. Pretty useful to come and go, switch from your PC to you iPad,... To choose another type of notebook, you have to shut down your current instance first. In JupyterLab, it's through File->Hub Control Panel (second from the bottom)->Stop My Server. It will then send the signal to JH to kill the pod. And now that JH knows you're not running anything, it will present you with the selection menu when you connect to it. NOTES:

• This explains why you can only have one instance of notebook per user. With multiple ones, JH would not know where to connect you.
• This explains the 4h. After timeout, meaning JH did not receive any interaction/command from your browser, it decides you're not using the pod anymore and initiates the shutdown by itself.
• The admin panel you connect to can also be useful to retrieve the Token that identifies you with JH. With this token you can directly interact with your notebook/pod, without your browser. Like work on your notebook from VSCode. The notebook is still running in the cluster, but you swap the interface from a browser to VSCode (different than opening a notebook in VSCode, in which case the kernel runs locally on your machine). Recipe: https://blog.jupyter.org/connect-to-a-jupyterhub-from-visual-studio-code-ed7ed3a31bcb

[romeokienzler]

Thanks @guimou this makes totally sense sorry for getting this wrong and wasting your cycles...

[guimou]

No worries. Plus the extended explanations may help someone else along the way. :smiley: