Remote Jupyter Server Ignoring jupyter.notebookFileRoot VS Code Setting

Environment data

• VS Code version: 1.63.2
• Jupyter Extension version (available under the Extensions sidebar): v2021.11.1001550889
• Python Extension version (available under the Extensions sidebar): v2022.1.5
• OS (Windows | Mac | Linux distro) and version: Ubuntu 18.04.6 LTS
• Python and/or Anaconda version: conda 4.11.0
• Type of virtual environment used (N/A | venv | virtualenv | conda | …): conda
• Jupyter server running: Local | Remote | Remove

Expected behaviour

Using Azure ML, I create to a new compute instance. I then connect to the compute instance via VS Code. I set jupyter.notebookFileRoot = ${fileDirname} in all contexts: User, Remote and Workspace. I expect that when I run !pwd in a cell in a Jupyter notebook for it to return the current directory that the notebook is running in.

/mnt/batch/tasks/shared/LS_root/mounts/clusters/my-compute/code/Users/OWilkins/azure-ml-project/notebooks/

Actual behaviour

Running !pwd instead prints this directory:

/mnt/batch/tasks/shared/LS_root/mounts/clusters/my-compute/code

Steps to reproduce:

1. Using Azure ML, create a new compute instance.
2. Connect to the compute instance via VS Code.
3. Inside the Settings UI set the jupyter.notebookFileRoot setting to ${fileDirname} for User, Remote and Workspace.
4. Create a directory inside your user folder called: azure-ml-project. Your file structure will most likely look something like this:

code
  Users
    your-username
      azure-ml-project

1. Create a notebook inside azure-ml-project.
2. Inside that notebook, run: !pwd.

I understand that this may be something specific to Azure ML and may be outside the remit of this repository but I am at a loss! Any help would be greatly appreciated!

[shsuman]

I think transferring this issue to our repository makes sense. Although, I think we should close this issue and open a new issue regarding removing the Compute instance option in the remote window. As far as I understand, everything explained in this issue is our current expected behavior and their is no underlying bug.

[SiddhanthUnnithan]

Thanks for bringing this to our attention @okwilkins – I can elaborate on the problem a bit.

I’m assuming you’re connecting to the compute instance from the Azure ML Studio? The bottom-left of the screenshots you sent show “Azure ML: owilkins-low-cost” as the resource indicator meaning that you’re connected to your compute instance through a remote VS Code window.

Within this window, all components (terminal, Jupyter server, debugger, extensions) are in the “remote” context. This means that when you connect to the “Default” Jupyter server, you’re connecting to a Jupyter server running on the compute instance. The Jupyter extension behaves as expected and understands the Notebook as it is on the compute – this is why when you !pwd you’re seeing the right path (cloudfiles/code/Users/<username>/azure-ml-project/notebooks).

The “Azure ML Compute Instance” option in the Jupyter server selector was meant to allow users to connect to their compute instances from their local Notebooks. Only the notebook, not the VS Code window, is connected to the remote compute. When the Jupyter extension creates the remote connection, they create a temporary Notebook at the root of the Jupyter server (cloudfiles/code/). This placeholder Notebook is then used to relay the commands of the local Notebook however all execution context is per the placeholder notebook. This is why when you run !pwd after choosing the “Azure ML Compute Instance” option you’re seeing the path as cloudfiles/code/ where cloudfiles == /mnt/batch/tasks/shared/LS_root/mounts/clusters/<my-compute>.

I think what is confusing in this experience is that once you’re connected to the remote compute (through the full window), we still surface “Azure ML Compute Instance” as an option. This doesn’t make sense as you’re already connected to the compute, so the default localhost option is connecting you to the right server. I think the right approach here is for us to hide the “Azure ML Compute Instance” option when you’re in the remote window. Keeping the option in the local window makes sense, as users that wish to only connect their local Notebooks to a remote compute can still do so in a streamlined way.