Opened 18 months ago

Last modified 5 weeks ago

#30313 new enhancement

Doc: Add instructions how to run a remote SageMath jupyter kernel

Reported by: mkoeppe Owned by:
Priority: major Milestone: sage-9.6
Component: documentation Keywords:
Cc: nbruin, embray, slelievre, gh-jcamp0x2a Merged in:
Authors: Reviewers:
Report Upstream: N/A Work issues:
Branch: Commit:
Dependencies: Stopgaps:

Status badges

Change History (13)

comment:1 Changed 18 months ago by mkoeppe

  • Cc nbruin embray slelievre added

On Windows, running the notebook in a native python installation and connecting to the Sage jupyter kernel running in cygwin would also be an attractive deployment option.

Last edited 18 months ago by mkoeppe (previous) (diff)

comment:2 Changed 18 months ago by mkoeppe

  • Description modified (diff)

comment:3 Changed 17 months ago by mkoeppe

  • Cc gh-jcamp0x2a added

comment:4 follow-up: Changed 17 months ago by nbruin

The title of this ticket seems to suggest a setup where the jupyter server process runs on one machine and the sage kernel runs on another. That's a tricky set-up. I don't think it's one we can expect to support any time soon. It opens a whole new can of worms where the Jupyter server file browser may show entirely different files than the ones that are available to the kernel process, since there might not be a shared filesystem between the two machines.

Another other problem is the added latency: In that set-up you'd have browser <-> jupyter server <-> kernel, with each of the arrows really needing to go over networking protocols. With the guarantee that the server and the kernel process are on the same machine, the server <-> kernel communication should end up being just local pipes, for which the operating system hopefully can figure out nice optimizations.

Third, the sage kernel needs quite a few plug-ins. Keeping those synced across different machines will be even more complicated. Not impossible, but I don't think advisable unless really required.

I think all we need is instructions to connect a browser to a remote server, which isn't really a sage-specific thing (but probably something that's worth helping people with).

comment:5 in reply to: ↑ 4 Changed 17 months ago by mkoeppe

Replying to nbruin:

The title of this ticket seems to suggest a setup where the jupyter server process runs on one machine and the sage kernel runs on another.

That's right.

Another other problem is the added latency: In that set-up you'd have browser <-> jupyter server <-> kernel, with each of the arrows really needing to go over networking protocols. With the guarantee that the server and the kernel process are on the same machine, the server <-> kernel communication should end up being just local pipes, for which the operating system hopefully can figure out nice optimizations.

Actually, the use case is exactly to improve latency, such as in an HPC environment. The head node of a shared cluster typically has abysmal interactive performance because dozens of users run stuff on it. One does not want to run the user interface on it!

Third, the sage kernel needs quite a few plug-ins. Keeping those synced across different machines will be even more complicated. Not impossible, but I don't think advisable unless really required.

Well, for example #30123 intends to fix exactly this: Replace ad-hoc installation of stuff into the notebook server by a more disciplined installation scheme: nbextensions. These can be managed and inspected in a robust and user friendly way.

comment:6 Changed 17 months ago by mkoeppe

  • Description modified (diff)

comment:7 Changed 17 months ago by mkoeppe

  • Description modified (diff)

comment:8 Changed 17 months ago by mkoeppe

  • Description modified (diff)

comment:9 Changed 17 months ago by mkoeppe

I've added a few links. (I haven't used any of these packages myself yet.)

comment:10 Changed 15 months ago by mkoeppe

  • Milestone changed from sage-9.2 to sage-9.3

comment:11 Changed 11 months ago by mkoeppe

  • Milestone changed from sage-9.3 to sage-9.4

Setting new milestone based on a cursory review of ticket status, priority, and last modification date.

comment:12 Changed 6 months ago by mkoeppe

  • Milestone changed from sage-9.4 to sage-9.5

comment:13 Changed 5 weeks ago by mkoeppe

  • Milestone changed from sage-9.5 to sage-9.6
Note: See TracTickets for help on using tickets.