yup, I saw the example code-server app at OSC github. - I discussed this already with some key users, and the known bug “In-app installation of extensions does not work” is quite showstopper - we all like syntax highlight, linters, etc…
Also the feeling of “native” app vscode is a factor…
After some research, I can tell that:
VS code can connect to remote jupyter server
I am able to extract connection information from logs and connection.yaml and connect to it from vscode
So the remaining task is to show this information somehow here - would you advice me, please, where in the codebase is this box drawn?
(and solve the network visibility between client and compute node indeed)
We are very interested to this too. @jose-d can you please elaborate on how you have been able to have VSCode connect to OOD-launched jupyter? I see two problems:
getting the appropriate token
reaching the compute nodes
At the moment I have a JupyterHub server (running on the head node, and submitting jobs to the compute node) and I would like to retire that. However users like the ability to just launch that, get the token (from the hub control panel) and connect via VSCode. On the other hand, network administrators like that they can keep the compute node behind the firewall.
@jeff.ohrstrom can you please elaborate a bit on the code server + Jupyter option and especially on the two issues? I’m not familiar with code server, so excuse me if the questions are too naive
in-app installation: is this something that I could workaround by doing global install as root? My user base is relatively small and relatively homogeneous, so that’s something I could live with, but I will need to install syntax highlighter and other extensions.
auth unencrypted: I don’t get this! If we are talking about a OOD app, how does it have its own authentication? Doesn’t it use just the OOD infrastructure including authentication?
sure. I must say it was regular slurm-started jupyter, it would need few tweaks to to the same in the jupyter OOD app, but principally doable:
at cluster (front-end node):
srun -N 1 --partition=gpu_int --gres=gpu:a100:1 --cpus-per-task=8 --mem=64000 --time=1-00:00:00 --pty bash -i
# command above will create interactive shell job with properly booked GPU, we're now in it..
# .. load any modules we like:
module load JupyterLab/3.5.0-GCCcore-11.3.0
module load CUDA/11.7.0
# run jupyter
this will get you lot of output including this:
To access the server, open this file in a browser:
Or copy and paste one of these URLs:
well and then, at my local laptop (edit: changed wording a bit), I started vscode, and created remote development session at login/front-end server (acting as a ssh jumpserver), then:
type in “Notebook select Notebook Kernel”
select “Another kernel”
select “existing jupyter server”
enter the URL of the running Jupyter server (- and there paste the URL from above)
…and that’s it.
It would be helpful, if using job templates or other OOD feature I’d be able to automatize the job launch, extract jupyter server URL, and display that in some user-friendly way.
Inbetween I realized that there is “tunnels” feature in vscode. Perhaps it could be more meaningful for our case.
I’m not entirely sure how to do this, but I would say that with a seperate app you can boot both applications, vscode & jupyter and connect them directly in the script.sh.erb.
Here’s an example where we boot Spark along with Jupyter. It’s a seperate application from the regular Jupyter application and does all the work of booting up Spark alongside Jupyter and connecting the two.
After some offline discussion, it has been recommended to me to inspect the HTML of the “Connect to Jupyter” button to see if I could find a way to connect to jupyter via an URL-only method which should work in VSCode, but that does not appear to work.
I think the problem is that OOD still tries to authenticate me via DEX. So if I set a token authentication in jupyter (perhaps with an actual token, rather than a empty one I would like to go to an URL like
I don’t think so. It seems very dangerous to me to leave these URLs open to anyone.
Thanks for sharing this comment.
To be clear, I’m not suggesting to leave it “open to anyone” but to simply proxy that URL to something else (jupyter in this case). Jupyter itself is not “open to anyone” but requires a password or token (which OOD provides under the hood in the current implementation, so you authenticate only once rather than twice).
What I was proposing, for this specific URL, is that OOD would just to the proxy to jupyter and let that handle the authentication.
If it’s too much of hassle or something to get it right, I understand – but I suspect others would keep asking since VSCode is quite popular already and gaining even more among the jupyter crowd, so…