Specify remote kernel in settings or environment variables

[realratchet]

Problem

Currently, the plugin does not provide a non-GUI way to specify which remote kernel to attach to. This is an issue because you cannot force the VSCode instance to start with specific remote kernel attached. Therefore the workflow of attaching to a remote kernel looks like this:

1. Click to open the dialog for remote server

2. Select existing

3. Specify the URL you want to connect to

4. Get prompted to restart the VSCode instance

5. Click select kernel in the notebook

6. And only then you select the actual notebook runtime

Outcome

This prevents you from performing any reasonable automation to connect to a persistent kernel instance.

Reason

Now you may be thinking, why would someone need this functionality? The reason is simple, the plugin right now does not provide any way to have persistent kernels working and instead spins up a new kernel for each VSCode instance, killing any active notebook state. To work around this, the suggestion is to have use remote kernels (#3571). However, the amount of user interaction it requires makes such feature unviable.

[DonJayamanne]

prevents you from performing any reasonable automation to connect to a persistent kernel instance.

please could you confirm the version of vscode and the extension. The latest version of the extension doest require users to reload vscode.
also when you exit and reload vscode, the connection should persist, hence there's no need to keep adding this again and again.

i believe you mentioned in discussions that you were using vscodium.
please could you confirm that

right now, i don't think there's any need for the feature you have requested, as you seem to be using an old version of the extension or vscodium that doesn't have the same functionally as vscode stable.

[realratchet]

Yes, I was using a bit older version for code-server. I updated to the newest supported plugin version, so the restart while not necessary, it does not actually populate the active kernel runtime list until you do restart (image). Without the restart middle section is not available.

code-server: v4.0.2
VS Code: v1.63.0
Commit: 5cdfe74686aa73e023f8354a9a6014eb30caa7dd
Date: 2022-01-27T22:22:39Z
Browser: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/96.0.4664.110 Safari/537.36

Jupyter: v2021.11.1001552333

I would be willing to integrate the changes into the older version of the plugin as I'm already attempting to navigate this code base to implement this myself, but it's a big code base so it's going to take a hot minute.

Additionally I have tested with this environment too:

Version: 1.64.2
Commit: f80445acd5a3dadef24aa209168452a3d97cc326
Date: 2022-02-09T22:02:29.527Z
Electron: 13.5.2
Chromium: 91.0.4472.164
Node.js: 14.16.0
V8: 9.1.269.39-electron.0
OS: Linux x64 4.19.0-6-amd64

Jupyter: v2022.1.1301854968

The same problems with the kernel selection list persist in both native VSCode and CodeServer. However, in either case, ideally this selection is something I want to bypass entirely.

[DonJayamanne]

does not actually populate the active kernel runtime list until you do restart (image). Without the restart middle section is not

this shouldn't be necessary, it's possible, its slow. please try reopening a notebook a few times to double check.
basically you don't need to reload bscode at all, if you do that's a bug.

However, in either case, ideally this selection is something I want to bypass entirely.

are you saying that you want the notebook to keep using the same kernel. if you are using a review kernel, then the extension will remember this and you will not have to select it everytime.
ie even after you reload vscode the same kernel is used, and you will not need to select it again.

[realratchet]

this shouldn't be necessary, it's possible, its slow. please try reopening a notebook a few times to double check.
basically you don't need to reload bscode at all, if you do that's a bug.

Nope, happens all the time with a new connection, it's fine with connection that was already saved and VSCode reloaded. And new connection only, if I were to switch to local and then to remote again it would detect them, but only if it was selected from the saved connection list.

are you saying that you want the notebook to keep using the same kernel. if you are using a review kernel, then the extension will remember this and you will not have to select it everytime.
ie even after you reload vscode the same kernel is used, and you will not need to select it again.

You are correct that the extension will remember this selection, the problem is, as far as I can tell there is no way to have this setting to be predefined. For example something like this:

"jupyter.jupyterServerType": "remote"
"jupyter.jupyterServerConnection": { "address": "http://localhost:8882", "kernel": "1234-1234-1234-1234" }

Right now the plugin automatically spawns a non-persistant kernel like so:

Info 14:27:02: Kernel Output: NOTE: When using the `ipython kernel` entry point, Ctrl-C will not work.

To exit, you will have to explicitly quit this process, by either sending
"quit" from a client, or using Ctrl-\ in UNIX-like environments.

To read more about this, see https://github.com/ipython/ipython/issues/2049


To connect another client to this kernel, use:
    --existing /tmp/tmp-22917W6KSkWZoqF30.json

What I would like is that it would connect to a persistent instance automagically without any user interaction, e.g., by overriding the workspace settings through backend. But for that I need some kind of interface with the plugin itself.

To sum up: I am trying to replicate ipython console --existing kernel-1234.json command in VScode using remote.

[DonJayamanne]

If you want to ensure the same kernel is always used for all notebooks, then I'll close this issue in favor of #9115

[realratchet]

I found within the codebase (serverUriStorage.ts@167) that if I set jupyter.jupyterServerType to ip:port it will actually cache the address to the list of remotes so that's half the functionality I wanted, the other is automatically selecting the persistent (ID is known before VSCode ever starts) kernel on vscode launch, so that variable state doesn't get nixed. Couldn't see any documentation for this jupyterServerType behavior.