Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Clarify restart to mean restart in-place #118

Merged
merged 3 commits into from
Nov 13, 2023
Merged
Changes from 2 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
60 changes: 60 additions & 0 deletions 118-restart-clarification/restart-clarification.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,60 @@
---
title: Restart Clarification
authors: Marc Udoff (@mlucool)
issue-number: [#117](https://github.com/jupyter/enhancement-proposals/issues)
pr-number: [#118](https://github.com/jupyter/enhancement-proposals/pull/118)
date-started: 2023-08-23
---

# Summary

The jupyter client protocol around what "restart" means is ambiguous. Per Jupyter Client's [kernel shutdown documention](https://jupyter-client.readthedocs.io/en/latest/messaging.html#kernel-shutdown), the only guidance is:
> 'restart' : bool # False if final shutdown, or True if shutdown precedes a restart

This has led to a situation where certain jupyter subprojects (e.g. enterprise gateway) have interpreted this to mean a "hard restart", or restart the whole process tree.

We propose to clarify this to always mean "restart-in-place", that is only restart the kernel itself. For
most usage of Jupyter, this change is a no-op as subprocess kernels already act like this.

# Motivation

This greatly improves the usability of remote kernels whose startup includes scheduling. By making this change,
restarts for remote kernels will be nearly as fast as those of local kernels. It also matches what we
believe to be the mental model of users when they click "restart".

# Guide-level explanation

The [protocol](https://jupyter-client.readthedocs.io/en/latest/messaging.html#kernel-shutdown) would describe
restart as optimally preserving as many resources outside the kernel as possible (e.g. restarting only the kernel process and its subprocess *not* any parent process).

When the kernel is a toplevel process (e.g. local kernels), there is no change.

When the kernel is not a toplevel process (e.g. when used in Enterprise Gateway), restart often means only the kernel restarts. To restart the whole progress group, the stop and start messages could be used. It's up to UIs
for how to display this difference (if any).

# Reference-level explanation

The `jupyter-client` messaging page would be updated to indicate this nuance. Any implementations that
treat restart differently would be updated to match this clarification.

# Rationale and alternatives

A new message could be added, as proposed in the pre-JEP. In the [Jupyter Server meeting](https://github.com/jupyter-server/team-compass/issues/45#issuecomment-1682582186),
we concluded that is is likely most users want restart to only restart the kernel and not potentially reschedule resources. Therefore, a new message was not the best option.
For the vast majority of kernels (local subprocesses), this change is a no-op because restart-in-place
is the same as a hard restart since it is the toplevel kernel process.
mlucool marked this conversation as resolved.
Show resolved Hide resolved

For users that want a hard restart, a stop followed by a start continues to be available. While this may be less convenient, a UI can trivially hide this two call process from the user.

# Prior art

N/A

# Unresolved questions

Only the exact wording changes as proposed in [jupyter_client](https://github.com/jupyter/jupyter_client/pull/966).

# Future possibilities

We would make a service that implements a "hard restart" as discussed in the juptyer-server meeting.
fcollonval marked this conversation as resolved.
Show resolved Hide resolved
No one on the meeting had an immediate use case for it.