You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It would be amazing if remote tunneling didn't force us into one server per machine (i.e. allow optional work around of #171520)
An amazing feature of tunnel is to be able to use it in HPC environments, for example starting up a tunnel through an sbatch job with specific allocated resources. This allows users to connect to the newly created tunnel and use vscode's debugging with specific resources managed through cluster management systems like slurm.
The issue is that if this happens more than once on a machine, any slurm allocation after the first will just point users to the tunnel of the first allocation, leading to conflict of resources. This would be an easy solution to workflow issues described in microsoft/vscode-remote-release#1722 .
Could supporting multiple tunnels on a machine be brought back?
The text was updated successfully, but these errors were encountered:
It would be amazing if remote tunneling didn't force us into one server per machine (i.e. allow optional work around of #171520)
An amazing feature of tunnel is to be able to use it in HPC environments, for example starting up a tunnel through an sbatch job with specific allocated resources. This allows users to connect to the newly created tunnel and use vscode's debugging with specific resources managed through cluster management systems like slurm.
The issue is that if this happens more than once on a machine, any slurm allocation after the first will just point users to the tunnel of the first allocation, leading to conflict of resources. This would be an easy solution to workflow issues described in microsoft/vscode-remote-release#1722 .
Could supporting multiple tunnels on a machine be brought back?
The text was updated successfully, but these errors were encountered: