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

[POC] Kernel and session rehydration and syncing #752

Closed
wants to merge 1 commit into from

Conversation

Zsailer
Copy link
Member

@Zsailer Zsailer commented Mar 24, 2022

I'm opening this as a proof-of-concept—it's not ready for thorough review.

Many enterprise deployments of Jupyter Server manage kernels remotely and separately from Jupyter Server via a separate service, i.e. kernel gateway and enterprise gateway. The advantage of this configuration is that kernels can persist past the lifetime of the Jupyter Server. This is particularly helpful if you need to upgrade the server/frontend but don't want to shutdown kernels.

A major challenge of this type of system is that it introduces distributed state for kernels. Today, we don't have a good, general way to synchronize the state of kernels (and client sessions) across such a system.

This PR proposes a solution—a Synchronizer class that watches, syncs, and persists kernels and sessions within and beyond the lifetime of a Jupyter Server. Kernels and Sessions can be "rehydrated" from a database at any time. This is mostly useful in a remote kernel situation, where kernels are provided by a service separate from Jupyter Server (e.g, kernel gateway or enterprise gateway). If the Jupyter Server goes down or is restarted (say, for an upgrade), this synchronizer can be used to repopulate the state. This works with pending, local, and remote kernels.

Lots of discussion and work to still do here (including adding unit tests and documentation).

I'll share at our Jupyter Server meeting tomorrow.

Depends on #751

Pinging @kevin-bates, since he is likely interested.

@Zsailer
Copy link
Member Author

Zsailer commented Apr 1, 2022

I'm considering moving this to its own extension that lives in another, experimental repo under the jupyter-server org. Thoughts?

@kevin-bates
Copy link
Member

I think this makes good sense @Zsailer. This will allow us to iterate on this independently of server release cycles. It is also something that a majority of installations (users) won't really make use of. Perhaps once things are stabilized we could consider its inclusion in the core server, but the reverse is more difficult. Thanks for proposing this approach.

@Zsailer
Copy link
Member Author

Zsailer commented Apr 5, 2022

Moved this PR to an extension here: jupyter-server/synchronizer#1

@Zsailer Zsailer closed this Apr 5, 2022
@Zsailer Zsailer deleted the synchronizer branch January 16, 2024 21:48
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants