potential conflicts with kernels

[rsettlage]

Hi, more of a question:

I see where kernels are moved from ~./local/share//kernel/ to /opt/...

What if there are kernels installed from other processes on the system? I do not see where python/conda are configured to look for kernels in /opt/... rather than ~/.local/share/

Thanks,
Bob

[haobibo]

Hi @rsettlage , by default, jupyter server will look for the kernels from at least two types of folders:

• the user prefix, which is ~/.local/share/kernel/...
• the system prefix, which is /opt/conda/share/jupyter/kernels

In QPod, our design is to let the kernels installed (or moved) to the system prefix, since we want leave the whole /root path to the user. You can use command jupyter kernelspec list to see all installed kernels and their paths.

Reference: https://github.com/jupyter/jupyter_client/blob/master/jupyter_client/kernelspec.py

[rsettlage]

Thanks @haobibo
right, the issue is that there could be main system kernels in there that are not compatible with the container. For instance, on an HPC cluster, users can have kernels installed for other workflows using the host OS. I have found where you can ADD to the search path for kernels, but not limit it, ie I am wanting to NOT look in the ~/.local/share/...

Are you suggesting I edit the line:
from jupyter_core.paths import jupyter_data_dir, jupyter_path, SYSTEM_JUPYTER_PATH
to filter out the ~/.local/share/kernel/...? Are there other ramifications of doing that?
Thanks

[haobibo]

I just got your needs. I wonder if this will work (you can modify the docker image to adapt your HPC env):

1. move those kernels that have conflicts with your env, in the /opt/conda/share/jupyter/kernels folder, to somewhere else (or just delete them).
2. create kernels for you HPC env (install them as sys_prefix)

btw, you can remind the users to use which kernel by define a user-friendly kernel name.

[rsettlage]

@haobibo oops, I think we miscommunicated. I am not worried about the ones in the container. I am worried about ones created outside the container showing up in the JupyterLab choices when running JL in the container. The ones I am worried about are user installed, not system installed. As you state, we can suggest them to use user-friendly user names. Many newer users won't know to do that leading to support tickets. :(

The way I am doing this is by using Open OnDemand (openondemand.org) to essentially start an HPC job and then launch the containerized JL/JN. This is the reason for my concern about user installed kernels showing up. Deleting the ~/.local/share/kernel/... worked for my home and I can certainly do something like this in a job, but this seems like the wrong approach if there is a way to simply limit the directories the containerized JL looks in for available kernels.

[haobibo]

Ah, actually you can limit/customize the behavior of the "kernel finder" - the KernelSpecManager.

Firstly, take a look at the config document of Jupyter notebook. The manager class can be set with config item: NotebookApp.kernel_spec_manager_classType. By default, it is set to jupyter_client.kernelspec.KernelSpecManager:
https://jupyter-notebook.readthedocs.io/en/stable/config.html?highlight=KernelSpecManager

If you go to that class, you will see a variable kernel_dirs - this is the list of folders where jupyter will find all the kernels: https://github.com/jupyter/jupyter_client/blob/master/jupyter_client/kernelspec.py#L142

And this will leads us to: jupyter/jupyter_client#175

So, I guess one easy way to achieve the goal is to develop a class that extends jupyter_client.kernelspec.KernelSpecManager, and configure it in NotebookApp.kernel_spec_manager_classType.

[rsettlage]

Hmm, ok, will give that a go. Thanks!