Using your IDE via a Compute Node🔗
While SSHFS via VS Code gets you close to your local development environment on H4H, it does not allow you to do things like interactive debugging.
Luckily, Microsoft provides the Remote-SSH VS Code extension which allows you to run a remote version of VS Code over an SSH connection which your local IDE can connect to.
only on Compute Nodes
H4H users are not permitted to run programs like VS Code on the login node or data node
as these nodes provide shared resources for all users. However, you can run VS Code on a compute node using SSH port forwarding.
Remote-SSH🔗
The Remote-SSH extension can be installed via the extensions panel in your local VS Code instance. See the documentation linked in References for more details on using this extension.
To setup a remote SSH connection you first need to know the name of the node you get allocated to setup the correct SSH configuration. SSH into the Login node and allocate an interactive job, noting the node you are assigned. Note this method should also work to SSH into batch jobs.
Try it yourself🔗
-
Connect to the H4H login node and allocate a new interactive job
-
Open the Command Pallete (CTRL/CMD + Shift + P) and type: "Remote-SSH" and select the "Open SSH Configuration File" option. This will open your SSH config file where you need to add the following lines, filling in the sections inside angle brackets with your own information:
```sh Host h4hcomputenode ProxyJump <username>@h4huhnlogin1.uhnresearch.ca HostName <allocated_node> User <username> ``` -
Save your SSH config and establish you connection using the Command Palette (CTRL/CMD + Shift + P) "Remote-SSH: Connect to Host" option and select h4hcomputenode. This will open a new VS Code window and attempt to connect to the compute node. It will ask you to select the Remote VM OS, pick Linux. It will also prompt you for your password (possibly several times) as well as ask if you trust the remote machine if it is your first time connecting to this node.
-
Once the connection is established, it will take a few minutes to copy the required remote software to the node. When it is done, you should be able to interact with the Compute node like a local machine.
Windows WSL
Note if you are using WSL on Linux you need to connect to the VPN from Windows, since this is where the process for Remote-SSH is run.
-
At the time of writing this tutorial it seems like you will need to update your SSH config file with the correct node every time you allocate a new remote session. If someone finds a work around for this please feel free to add a section to this document!
Installing VS Code Extensions on H4H🔗
Unlike mounting H4H drives via SSHFS, the back-end for VS Code is not running on your local machine but on the Compute node. As such, some extensions will not work until they are also installed on H4H. Installing Remote extensions requires you to first install them using the build node. You can add an entry to your SSH config file to make connection easy:
Host uhnslurmbuildbox
ProxyJump <username>@h4huhnlogin1.uhnresearch.ca
HostName uhnslurmbuildbox
User <username>
Note you need to allocate a job on this node before you can establish a
connection. Extensions installed on the build node are located in your home
directory on H4H and therefore persist as long as the appopriate directory
exists. Similar to installing custom packages via conda you should install
the minimum number of extensions for analysis to ensure you don't exceed the
50 GB drive quota in your home directory.
That being said, there are tons of useful extensions for VS Code that you can install to make interacting with the cluster easier. This includes full featured interactive debuggers for languages like R and Python, extensions allowing you to view image files or PDFs directly in VS Code, render plots interactively as well as work with Jupyter Notebooks or Rmarkdown documents that live on the cluster.
It is worth noting as well that you are able to submit jobs while connected to a Compute node. Thus it is possible to allocate an interactive job with a relatively small resource request (4-8 cores, 8-16 GB of RAM) where you can run your IDE and edit code files while still being able to deploy jobs like you are on the Login node. A setup such as this would be ideal for regular development on the clusters, but you may need to request additional resource if you are debugging a large job which requires specific hardware like a GPU or lots of RAM.