Differences
This shows you the differences between two versions of the page.
Next revision | Previous revision | ||
software:vscode:vscode [2023-10-05 10:28] – created anita | software:vscode:vscode [2023-10-11 11:31] (current) – [Appropriate use of RCI Clusters as a VSCode Backend] thuachen | ||
---|---|---|---|
Line 1: | Line 1: | ||
+ | ====== Appropriate use of RCI Clusters as a VSCode Backend ====== | ||
+ | [[https:// | ||
+ | The **Remote-SSH** extension enhances the VSCode' | ||
+ | |||
+ | There are several issues with this when the target environment is an HPC cluster: | ||
+ | |||
+ | * The remote infrastructure (shell and Python scripts) is left running indefinitely. | ||
+ | * Users who become reliant on VSCode as a production environment will inevitably have their work killed (since it will be executed outside of job scheduling). | ||
+ | * Any specialized hardware (like GPUs, large RAM) is not present in login nodes. | ||
+ | |||
+ | The clusters currently in production at UD have multiple login nodes balanced via round-robin DNS resolution of a single hostname. With regard to the first point above, the local VSCode application will " | ||
+ | |||
+ | An attempt at proxying VSCode remote sessions through the cluster job scheduler seemed like a worthy project. If the VSCode app's shell commands were forwarded to an interactive job running on a compute node, then the remote execution infrastructure would: | ||
+ | |||
+ | * have access to specialized hardware by virtue of the parameters associated with the interactive job. | ||
+ | * not consume significant CPU resources on the login node. | ||
+ | * be automatically terminated when the interactive job is completed. | ||
+ | |||
+ | <note important> | ||
+ | |||
+ | ===== Details by cluster===== | ||
+ | * [[software: | ||
+ | * [[software: |