jupyter / jupyter_client

Jupyter protocol client APIs
https://jupyter-client.readthedocs.io
BSD 3-Clause "New" or "Revised" License
390 stars 284 forks source link

Create a kernel with specified custom ports #955

Open jkitchin opened 1 year ago

jkitchin commented 1 year ago

I am trying to start a jupyter kernel like this:

jupyter-kernel \
       --ip=0.0.0.0 \
       --KernelManager.control_port=56406 \
       --KernelManager.hb_port=56407 \
       --KernelManager.iopub_port=56408 \
       --KernelManager.shell_port=56409 \
       --KernelManager.stdin_port=56410

It starts, and I see this output:

[KernelApp] Starting kernel 'python3' [KernelApp] Connection file: /Users/jkitchin/Library/Jupyter/runtime/kernel-892382b5-8115-44ba-95cd-d8172ba848ac.json however, the kernel json contains:

cat /Users/jkitchin/Library/Jupyter/runtime/kernel-892382b5-8115-44ba-95cd-d8172ba848ac.json
{
  "shell_port": 55505,
  "iopub_port": 55506,
  "stdin_port": 55507,
  "control_port": 55509,
  "hb_port": 55508,
  "ip": "0.0.0.0",
  "key": "0a163fda-2b4963c994abc4277bdf58fa",
  "transport": "tcp",
  "signature_scheme": "hmac-sha256",
  "kernel_name": ""
}

which do not match the ports I specified. Am I missing something to make this happen?

kevin-bates commented 1 year ago

This is due to the KernelManager.cache_ports value of True (which is the trait's default for transport == tcp). Unfortunately, this trait is not marked as configurable, so I'm not sure there's a way to adjust this from a configuration file or the command line. I raised this concern a few years ago (after the port caching feature was implemented) but it was never addressed.

I see now that this is a duplicate of #878.

jkitchin commented 1 year ago

I can confirm the issue is with KernelManager.cache_ports. Thanks for the tip. At https://github.com/emacs-jupyter/jupyter/issues/481#issuecomment-1622725743 I patched this and then it works as one would expect it to. I don't know if it is a general solution for others who want to use this, but it probably beats forking it.

kevin-bates commented 1 year ago

Hi @jkitchin - thanks for taking a closer look.

I think we can make cache_ports configurable by adding the config=True keyword argument into its "declaration" on L185 and similar to the shutdown_wait_time declaration. For completeness, we might as well add the default value of False argument prior to config=True.

This would then enable the use of --KernelManager.cache_ports=False on your command line, allowing custom port definitions to occur.

Would you like to contribute that pull request? It would resolve both this issue and #878, so it would a desirable change.

jkitchin commented 1 year ago

I made a pull request above. I have tested it locally, and it seems to do the right things. The logic is confusing to me though. The default is set to False, but if you don't set --KernelManager.cache_ports=False then it does cache the ports, and if you do set that, it does not cache the ports.

kevin-bates commented 1 year ago

The logic is confusing to me though. The default is set to False, but if you don't set --KernelManager.cache_ports=False then it does cache the ports, and if you do set that, it does not cache the ports.

Welcome to traitlets. This package does some magic stuff. In this case, there's already a "defaults handler" which overrides the False default with its return value. I hesitated suggesting adding the explicit False indicator, but I find it a more complete declaration, fwiw. This is why ONLY setting CLI option (or configuring that option via a configuration file) will appear to not cache the ports (when using transport==tcp, which is the transport trait's default).

genatin commented 1 year ago

This is due to the KernelManager.cache_ports value of True (which is the trait's default for transport == tcp). Unfortunately, this trait is not marked as configurable, so I'm not sure there's a way to adjust this from a configuration file or the command line. I raised this concern a few years ago (after the port caching feature was implemented) but it was never addressed.

I see now that this is a duplicate of #878.

Yeah, it's customizable right now. Thanks, man