vscode-jupyter
vscode-jupyter copied to clipboard
microsoft
Support connecting to multiple remote servers at once
Discussed in https://github.com/microsoft/vscode-jupyter/discussions/11227
Originally posted by mkarikom August 31, 2022
Background:
Sometimes it's nice to be able to explore two different versions of some code. In the notebook context (at least in vscode), this seems to require separate kernels. My understanding is that (at least in vscode), having two separate kernels requires two separate servers. For kernel persistence (remote connection here can be dodgy), these two servers are started as "remote servers" as below.
Issue (server for notebook 2 replaces server for notebook 1):
Note: this scheme already works great for the case with a single notebook/ jupyter server
For each of two notebooks, I open up a screen session and run the following (each kernel has a unique port):
- create a server for notebook 1:
jupyter notebook --no-browser --port=9996 --config=/workspaces/working_repo/.devcontainer/jupyter_notebook_config.json - create a server for notebook 2:
jupyter notebook --no-browser --port=9997 --config=/workspaces/working_repo/.devcontainer/jupyter_notebook_config.json - open notebook 1 and select the jupyter server on port 9996.
- open notebook 2 and select the jupyter server on port 9997
- go back to notebook 1 and notice that the server has been overridden (it now tries to use the one on port 9996)
mkarikom thanks for the suggestion. Out of curiosity what's the workflow here, i.e. why do you want to try to run a notebook against two servers. Is it to test the performance of sometime against say one server that has GPU vs another without GPU or the like. Or is it to test with different versions of python packages or the like.
Also, is the code identical and just executed against two different kernels?
Asking because at one point we did explore allowing users to connect to more than one server at a time, however we abandoned this idea as we didn't feel users would require such a feature.
Closing as dupe of #1352 as that covers the same scenario. This is resolved in the new prototype picker work, but leaving 1352 open until that's actually being rolled out.
