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.

Sign up for GitHub

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

Jump to bottom

Meeting Notes 2024 #57

Open
Zsailer opened this issue Jan 4, 2024 · 25 comments
Open

Meeting Notes 2024 #57

Zsailer opened this issue Jan 4, 2024 · 25 comments

Comments

@Zsailer
Copy link
Member

Zsailer commented Jan 4, 2024 •
edited

Hello everyone,

Gitter

Welcome to the Jupyter Server Team!

We meet on Thursdays at 8:00am, Pacific Standard Time on Jupyter's Zoom Channel.You can add yourself to the weekly agenda here. Everyone is welcome!

Let's avoid using this thread for discussion. If you'd like to discuss something in the minutes, open a separate issue and reference this thread.

You can find previous year's notes here: 2020, 2021, 2022, 2023

Meeting Notes
@Zsailer Zsailer pinned this issue Jan 4, 2024
@Zsailer Zsailer mentioned this issue Jan 4, 2024
Closed
@Zsailer
Copy link
Member Author

Zsailer commented Jan 4, 2024

January 4th, 2024

Name affiliation username
Zach Sailer Apple Zsailer
Johan Mabille QuantStack @JohanMabille
Andrii Ieroshenko AWS @andrii-i
Ian Thomas QuantStack @ianthomas23
David Brochart QuantStack @davidbrochart

Agenda

  • Zach
    • New year, new meeting thread!
    • Membership maintenance check closes tomorrow.
      • Thank you, everyone, for a great year!
    • Port kernel gateway to Jupyter Server 2.x
      • Thank you, Kevin, for doing a majority of the work! 👏
      • Requires a major release (3.x) and maintenance of the old branch (2.x)
      • I will announce on discourse once released.
      • Ran into issues getting the websocket subprotocol working, so the Gateway client defaults to the legacy protocol.
    • Would anyone else like to moderate the Jupyter Server meeting?
    • Also, new year means we should run a fresh election for Jupyter Server representative.

@Zsailer
Copy link
Member Author

Zsailer commented Jan 18, 2024

January 11th, 2024

Name affiliation GitHub username
Zach Sailer Apple Zsailer
Vidar Fauske JP Morgan Chase vidartf
Jason Grout Databricks @jasongrout
Sylvain Corlay QuantStack @QuantStack
Ian Thomas QuantStack @ianthomas23
David Brochart QuantStack @davidbrochart
Johan Mabille QuantStack @JohanMabille
Andrii Ieroshenko AWS @andrii-i

Agenda

  • Zach

    • schema.jupyter.org progress
      • Add first set of schemas and a simple Python package for distributing schemas jupyter/schema#1
      • Requirements for this repo
        • Installs schemas on disk somewhere (python package?)
          • The current PR uses a Python package
        • Makes schemas available from schema.jupyter.org (permanent URLs)
        • Import schemas at runtime (in any language, in principle)
        • Generate types from schemas in any language, in principle
        • CLI as a Jupyter core application
      • Question: what schemas should go here?
        • event schemas from subprojects
        • specs for connection_file
        • specs for the kernelspec
        • specs for the kernel protocol
        • specs for jupyter mimetypes
        • jupyter_server OpenAPI spec
          • some discussion around this point.
          • there is a difference between the API surface and what the handlers do in response to that API. Maybe we can start by formalizing the API service.
      • Ownership of schemas
        • Which subproject owns this repo?
          • [@jasongrout] Foundations and Standards seems like the natural home
        • Is this the source of truth for schemas? For example, is nbformat the home for the nbformat schema, and it's copied here, or does the official schema live here?
          • [@jasongrout] It's nice having nbformat schema co-located with the tools that work with it, for example. Though I suppose it's not too much of a stretch to have the nbformat package depend on the schemas package.
      • Package versioning
        • Do we ship a separate package for each schema? Or do we bump the package for any schema update?

  • Sylvain / Ian: Subshells

    • Add JEP for sub-shells jupyter/enhancement-proposals#91
    • Ian is planning on summarizing the current state of the work over the last few years
    • Two main approaches have been discussed
      • "Subshells": A single thread running a message router to different execution threads
        • Everyone's mental modeling of threading works
      • "Dependent kernels": Multiple execution threads, each with their own ZMQ channels (except control channel is shared), so it appears to the outside world as a collection of independent kernels
        • Pretend like it's a kernel and things "just work"
        • Except lifecycle is slightly more complicated because control thread is shared. For example, what does it mean to shutdown a kernel? Do we shut down the single thread, or the whole process?
    • Ian showed demos of the "dependent kernels" approach
    • There was discussion about how multiple threads interact with status messages. Right now status messages are sent for control message processing, which breaks the mental model for status messages.
    • Are there concerns about multiple threads interacting with the same display objects? Is it possible to do it in a thread safe manner? Or should diplay objects be owned by specific threads? What is the case for multiple clients?
      • [@jasongrout] I used to think the GIL protects us there, but some things I read recently helped me realize Python multithreading can be really tricky. (1, )
        • PEP 703 maybe not always rely on GIL?
    • Possibly in the future, status messages indicate busy/idle status for a single execution thread.
    • What's next?
      • QuantStack has funding to work on this, and is planning on working through the Jupyter process in the next 4-6 months with implementation landing within a year
      • We need to decide the basic approach, so have a discussion and move forward

  • David

    • YDrive: CRDT-based contents API
    • Will implement something for JupyterLab for this collaborative drive. Starting today.

@Zsailer
Copy link
Member Author

Zsailer commented Jan 25, 2024

January 18th, 2024

Name affiliation GitHub username
Zach Sailer Apple Zsailer
Johan Mabille QuantStack @JohanMabille
Jason Grout Databricks @jasongrout
Mike Krassowski Quansight @krassowski
Vidar Fauske JP Morgan Chase @vidartf
Ian Thomas QuantStack @ianthomas23
David Brochart QuantStack @davidbrochart
Andrii Ieroshenko AWS @andrii-i
William Stein SageMath, Inc. @williamstein

  • Mike

  • Ian Thomas

    • Update on concurrent kernels (subshells)
    • Add JEP for sub-shells jupyter/enhancement-proposals#91 (comment)
    • We spent ~5 minutes reading the newest update then opened for discussion.
    • Could it be that different dependent kernels have different ip addresses, i.e., totally different connection files?
      • Ian was thinking the connection file for the new dependent kernel just has a different shell port
      • If you have a different ip address, dependent kernels becomes multi-processing instead of multi-threaded
    • Dependent kernels require quite a bit of server changes
    • If we make the feature optional, the dependent kernels may be easier since you don't have to modify the kernel protocol
    • How backwards compatible is the approach for clients that support concurrent kernels, but kernels that don't?
      • subshells: the kernel just ignores the subshell field and messages are considered in order. The guarantee is that messages in a single subshell are processed in order.
      • dependent kernels: the api just hands back
    • the big question i have is how this kernel metadata stored in the notebook format? the notebook document stores compute information in its metadata. will subshells be marked up in the cell metadata to describe compute?
      • For many users, they won't use concurrent execution. Mostly the system uses concurrent execution
    • How are concurrent executions recorded in a notebook? Execution counter? Do different cells store which dependent kernel they use?
    • How does reactive execution work with this? For example, ipyflow (see paper here)

  • Community survey for kernels?

@Zsailer
Copy link
Member Author

Zsailer commented Feb 1, 2024

January 25th, 2024

Name affiliation GitHub username
Zach Sailer Apple Zsailer
William Stein CoCalc/SageMath @williamstein
Vidar T Fauske JP Morgan Chase vidartf
David Brochart QuantStack @davidbrochart
Johan mabille QuantStack @JohanMabille
Ian Thomas QuantStack @ianthomas23
Afshin T. Darian QuantStack @afshin
Jason Grout Databricks @jasongrout

  • Zach

    • Jupyter Server Representative nominations

  • Johan

    • Jupyter Kernels Representative nominations (ends February 1st)

  • Questions:

    • Is there a Jupyter project wide approach to documenting supported/deprecated Python versions (like NEP 29)?
    • If I write an extension today, can I target JupyterLab only or is there an expectation that I also support the classic notebook?
      • It depends on your audience.
      • There isn't an expectation to write extensions for both.
      • Notebook v7 makes it easier to write extensions that work in both.

  • [Ian] Update on concurrent execution? (requested by @jasongrout)

    • Next step: comments from community about what Ian has written
    • If no comments, update the JEP
    • @jasongrout and @Zsailer both have usecases that would benefit from concurrent execution

@Zsailer
Copy link
Member Author

Zsailer commented Feb 8, 2024

February 1st, 2024

Name affiliation GitHub username
Zach Sailer Apple @Zsailer
Michał Krassowski Quansight @krassowski
William Stein SageMath @williamstein
Ian Thomas QuantStack @ianthomas23
Kevin Bates Veritone @kevin-bates
David Brochart QuantStack @davidbrochart

Agenda

@Zsailer
Copy link
Member Author

Zsailer commented Feb 15, 2024

February 8th, 2024

Name affiliation GitHub username
Zach Sailer Apple @Zsailer
Johan Mabille QuantStack @JohanMabille
Ian Thomas QuantStack @ianthomas23
Steve Silvester MongoDB @blink103
David Brochart QuantStack @davidbrochart
Mike Krassowski Quansight @krassowski

Agenda

Question:

@Zsailer
Copy link
Member Author

Zsailer commented Feb 22, 2024

February 15th, 2024

Name affiliation GitHub username
Zach Sailer Apple @Zsailer
Ian Thomas QuantStack @ianthomas23
Jason Grout Databricks @jasongrout

@Zsailer
Copy link
Member Author

Zsailer commented Feb 29, 2024

February 22nd, 2024

Name affiliation GitHub username
Jason Grout Databricks @jasongrout
Sergey Kukhtichev IBM @skukhtichev
David Brochart QuantStack @davidbrochart
Johan Mabille QuantStack @JohanMabille
Ian Thomas QuantStack @ianthomas23

Agenda

@Zsailer
Copy link
Member Author

Zsailer commented Feb 29, 2024

February 29th, 2024

Name affiliation GitHub username
Johan Mabille QuantStack @JohanMabille
Vidar T Fauske JP Morgan Chase @vidartf
Zach Sailer Apple @Zsailer
Steve Silvester MongoDB @blink1073
Ian Thomas QuantStack @ianthomas23

Agenda

  • [Steve] Async Updates across the stack

    • Merged Ian's work to remove control queue from IPykernel
    • Combine this with David's work to remove Tornado IOLoop
    • Steve is working on grafting these two things together, which is proving to be challenging.
    • Zach and Steve are working on getting a new implementation of Async Kernel Manager out to remove ZMQ Stream and Tornado IOLoop.

  • [Nick] Schema repo discussion

    • Let's not do any RST for documentation.
    • Markdown forward.
    • That's aim for tooling that works both locally and on CI.
    • Get rid of Makefile
    • Add sphinx autobuild
    • Validate URI of schemas against their location in the repo
    • We should spend some time thinking about URI structure
      • Namespacing shouldn't be a question of "which project owns this schema", such as /jupyter_server/ or jupyter_client
      • Intead, let's namespace based on nouns, e.g. /server/, /kernels/, etc.

@Zsailer
Copy link
Member Author

Zsailer commented Mar 7, 2024

March 7th, 2024

Name affiliation GitHub username
Zach Sailer Apple @Zsailer
Jason Grout Databricks @jasongrout
David Brochart QuantStack @davidbrochart
Ian Thomas QuantStack @ianthomas23
Steve Silvester MongoDB @blink1073

Agenda

  • [Steve] Releases and security updates
    • PR merged in server for enhanced security around release actions
    • Using a Github App for publishing. No longer using Github Admin Token. This also solves the issue of having to regularly update the token.
    • Can't use this for NPM yet.
    • Private release feature in jupyter-releaser (thanks Fred)
      • Useful for security patch releases; using a two part
        1. Publish to PyPI and create a tag.
        2. (1 week later) publish changelong and Github release using a separate workflow
  • [@jasongrout] Linux Foundation proposal
    • There is an open issue for discussion.
  • [@jasongrout] What is the current status of the prototype for concurrent kernel execution?
    • We might experiment with this at Databricks next week in an engineer hackathon
    • The current prototype is definitely demo code. You can create subshells, you can send execute requests. Potentially the status info is off. The main thread is a router instead of the main execution thread, where it needs to be. You can't delete subshells yet.
    • Anyio prototype is also in progress, and could impact the subshell work. David was working on this, but it has passed over to Steve now. This would make ipykernel asyncio-first, and would simplify future developments. Advantages: support for trio and uvloop.
    • related: AnyIO support in pyzmq
      FEAT: support AnyIO zeromq/pyzmq#1827

@Zsailer
Copy link
Member Author

Zsailer commented Mar 21, 2024

March 14th, 2024

Name affiliation GitHub username
Zach Sailer Apple @Zsailer
Ian Thomas QuantStack @ianthomas23

Agenda

  • [Zach]
    • General announcements for Jupyter Server Team
      • Please read, review, comment (if you'd like) on the move to Linux Foundation proposalLinux Foundation proposal
      • Voting has opened for the Executive Council

@Zsailer
Copy link
Member Author

Zsailer commented Mar 28, 2024

March 21st, 2024

Name affiliation GitHub username
Jason Grout Databricks @jasongrout
David Brochart QuantStack @davidbrochart
Ian Thomas QuantStack @ianthomas23
Omar Jarjur Google @ojarjur
Zach Sailer Apple @Zsailer
Johan Mabille QuantStack @JohanMabille

Agenda

  • [Ryan, Gabriel, Jason] Lessons from exploring implementing the subshell demo in Databricks

    • Overall, the demo worked great!
    • Parent headers are per channel (e.g., "control", "shell"), so are inaccurate for subshells. We hacked a parent header per subshell
    • Recent changes for output per thread and eliminating the control queue conflict with the subshell prototype
    • We didn't finish swapping the main thread to be code execution instead of message routing, so interruption still didn't work
    • We added a shell_id parameter to create_subshell_request so we could explicitly set a subshell id (and thereby consolidate subshell ids if desired)
    • We changed the name of the thread to be shell-{name} to aid in debugging
    • Is there a reason we are using zmq/pickling instead of a Python Queue or SimpleQueue to communicate messages between threads?
    • Thread safety issues are tricky (like autocomplete requests might run 3rd party library code that assumes single-threaded)
    • Read up on subinterpreters coming in Python 3.13. Perhaps spawning a subinterpreter is a different kind of subshell, or perhaps subinterpreter is well-suited to a dependent kernel approach

  • [Omar] Requesting feedback on Navigating in the JupyterLab UI can prevent idle kernels from being culled. jupyter_server#1360

Reminder:

  • EC council election is currently going on, see your email if you are on a Jupyter council or committee
  • Linux Foundation proposal is currently under discussion

@Zsailer
Copy link
Member Author

Zsailer commented Apr 11, 2024

March 28th, 2024

Name affiliation GitHub username
Zach Sailer Apple @Zsailer
David Brochart QuantStack @davidbrochart
Piyush Jain AWS @3coins

Agenda

  • Zach

    • I can't host contributing hour today.

  • Ryan

    • debugger not working on background thread

  • Piyush

  • This issue was reported on gitter a few weeks back. Are there any suggestions on how to fix this.

    • Discussed the issue and the next step is to open an issue with all the information. Zach mentioned that this could be a regression from server 1.0, so should try with that. There is also an env variable JUPYTER_SERVER_ROOT which is not configurable at the moment, but could be made into a configurable, which can help nudge the CWD for terminals at runtime.

Bug around inaccurate execution_state in the client
- jupyter-server/jupyter_server#1395
- jupyter-server/jupyter_server#990

@Zsailer
Copy link
Member Author

Zsailer commented Apr 11, 2024

April 4th, 2024

Name affiliation GitHub username
Ian Thomas QuantStack @ianthomas23
R Ely Bloomberg @ohrely
Jason Grout Databricks @jasongrout
Maico Timmerman Adyen @MaicoTimmerman

Agenda

  • Ely:

  • Darian:

  • Jason: update on async kernel execution?

    • Ian may be able to start working on this a few weeks from now
    • Jason may be able to find some engineering time as well to coordinate with Ian on writing an implementation in May/June.
    • There are concerns about the tests that are broken with the anyio changes.
    • No one is currently actively working on the any-io test failures, but Ian has worked on at least one.

  • Maico: I'm looking for some support on an MR on the enterprise-gateway. I was hoping to utilize the meeting to get in touch with the correct person.

@Zsailer
Copy link
Member Author

Zsailer commented Apr 25, 2024

April 11th, 2024

Name affiliation GitHub username
Zach Sailer Apple @Zsailer
Jason Grout Databricks @jasongrout
David Brochart QuantStack @davidbrochart
Afshin T. Darian QuantStack @afshin
Johan Mabille QuantStack @JohanMabille
Ian Thomas QuantStack @ianthomas23
Mike Krassowski Quansight @krassowski
Steve Silvester MongoDB @blink1073

Agenda

@Zsailer
Copy link
Member Author

Zsailer commented Apr 25, 2024

April 18th, 2024

Name affiliation GitHub username
Zach Sailer Apple @Zsailer
Steve Silvester MongoDB @blink1073
Johan Mabille QuantStack @JohanMabille
Ian Thomas QuantStack @ianthomas23
David Brochart QuantStack @davidbrochart
Vidar Fauske JP Morgan Chase @vidartf
Mike Krassowski Quansight @krassowski

Agenda

@Zsailer
Copy link
Member Author

Zsailer commented May 2, 2024

April 25th, 2024

Name affiliation GitHub username
Zach Sailer Apple @Zsailer
David Brochart QuantStack @davidbrochart
Vidar Fauske JP Morgan Chase @vidartf
Afshin T. Darian QuantStack @afshin

Agenda

  • Zach
    • SSC Rep moving into voting phase today
      • Multiple candidates
      • Rank-based voting
      • Single transferable vote strategy for counting votes.
      • Apache STeVe software we'll use to run the vote.
    • Async start_extension hook: Add async start hook to ExtensionApp API jupyter_server#1417
    • I won't be able to run Contributing Hour anymore (at least for the time being). I'll remove the calendar invite.

@Zsailer
Copy link
Member Author

Zsailer commented May 9, 2024

May 2nd, 2024

Name affiliation GitHub username
Zach Sailer Apple @Zsailer
Steve Silvester MongoDB @blink1073
David Brochart QuantStack @davidbrochart
Luciano Resende Apple @lresende
Ian Thomas QuantStack @ianthomas23

Agenda

@Zsailer
Copy link
Member Author

Zsailer commented May 9, 2024

May 9th, 2024

Name affiliation GitHub username
Zach Sailer Apple @Zsailer
Vidar T Fauske JP Morgan Chase @vidartf
Mike Krassowski Quansight @krassowski
Steve Silvester MongoDB @blink1073
Ian Thomas QuantStack @ianthomas23
A T Darian QuantStack @afshin

Agenda

  • Zach

    • Announcing new Jupyter Server SSC Representative!
      • Congratulations to Vidar Fauske for being elected as the new Jupyter Server SSC Repo
      • How do we make election results more transparent?
      • Add an SSC Drive to host election forms
        • Zach will open an issue on governance?
    • Volunteers to run the Jupyter Server/Kernels weekly call?

  • Mike

    • restoring full state (related to server side execution)
      • https://github.com/datalayer/jupyter-server-nbmodel
      • three missing things:
        • removing pending execution state indicator and replacing with execution count,
        • stdin boxes
        • timing metadata
      • discussions: Notebook cell execution jupyter_ydoc#169
      • Mike asked Zach's opinion on if REST API proposal listed above is the "right" way to go?
        • Zach said this proposal was motivated by some issues he saw where we leak resources/websockets too easily in Jupyter Server
        • He was aiming to simplify the API by providing a REST API for kernel messages and leverage the Event APIs as the single source of structured/schematized websockets.
        • Mike pointed out that one challenge of this approach is that, because the request (via REST) and the reply (events websocket) are not going through the same API, the cache needed to track their relationship might be difficult to implement in a way that doesn't cause memory leaks.
      • Discussion about what model should live on the server?
        • Idea from Nick. Instead of a single document model; have a "workspace" CRDT model.
        • Make the ydoc changes looks something like JupyterLab commands.
        • These in-memory models are really "UI models", telling each client how to rebuild the UI exactly how the user left it.
        • Imagine CRDT in Voila; RTC on widgets in voila would be amazing.

@Zsailer
Copy link
Member Author

Zsailer commented May 23, 2024

May 16th, 2024

Name affiliation GitHub username
Zach Sailer Apple @Zsailer
Vidar T Fauske JP Morgan Chase @vidartf
Frederic Collonval WebScIT / Datalayer @fcollonval
Johan Mabille QuantStack @JohanMabille
David Brochart QuantStack @davidbrochart
Ian Thomas QuantStack @ianthomas23

Agenda

@Zsailer
Copy link
Member Author

Zsailer commented May 23, 2024

May 23rd, 2024

Name affiliation GitHub username
Zach Sailer Apple @Zsailer
Johan Mabille QuantStack @JohanMabille
Ian Thomas QuantStack @ianthomas23
Piyush Jain AWS @3coins
Steve Silvester MongoDB @blink1073
Afshin T. Darian QuantStack @afshin
Frederic Collonval WebScIT / Datalayer @fcollonval

Agenda

  • Steve - recap of PyCon US 2024

    • Highly recommended talk from Anthony Shaw Unlocking the Parallel Universe: Sub Interpreters and Free-Threading in Python 3.13
    • Packaging Summit - we're working toward a Packaging working group, along with a dedicated effort at the PSF level including a UX expert for "onboarding onto Python", which may include a "blessed" workflow, documentation, new tool(s), etc.
    • Pittsburgh is great - try to go next year! - Try the Primanti Sandwich
    • The next location will be Long Beach, CA in 2026-27.

  • Ian - subshells (JEP91) real implementation in progress

    • Aiming for more accessible demo (e.g. via binder) for people to play with.

  • Discussion around Jupyter extension long-term support

    • Looked at CNCF's incubation project for guidance
    • Jupyter has less people resources
    • https://github.com/jupyter/docker-stacks
      • A great way to show opinion combinations of Jupyter pieces together and tests that they work together

  • Frederic

    • Discussion to collaborate on an extension implementing a kernel state machine on the server side; final goal would be to upstream it when stable.
    • Zach will open two lines of work
      • One on Jupyter Client with Async kernel manager
      • A new repo with a server extension and customer kernel manager with a kernel state machine

@Zsailer
Copy link
Member Author

Zsailer commented Jun 6, 2024

May 30th, 2024

Name affiliation GitHub username
Vidar T Fauske JP Morgan Chase @vidartf
Piyush Jain AWS @3coins
David Brochart QuantStack @davidbrochart
Zach Sailer Apple @Zsailer

Agenda

  • Zach
    • Next generation kernels API
      • Problems I'm trying to solve:
        1. the control and shell channel states are conflated.
        2. the kernel client on the server doesn't "know" the state of the kernel. For example, if the client is disconnected when the kernel state changes, recovering the true state isn't easy.
        3. every kernel websocket opens a new set of ZMQ sockets. This presents multiple issues, e.g. 1) ZMQ sockets are resource limited 2) it's difficult to track all of the places where messages are flowing (making (3) difficult to get right) 3) today, we're leaking sockets somewhere (Zach has seen this for long running servers, but hasn't tracked the cause)
      • Proposal to fix
        • (1) include the parent channel in the iopub messages, or track these messages server-side to distinguish status messages from shell/control.
        • (2) track two types of kernel states in the server (via KernelManagers)
          • lifecycle state, (e.g. starting, started, connecting, connected, terminating, terminated)
          • execution state, (busy, idle, unknown, dead)
          • Add a REST API (?) for fetching kernel state anytime the client needs to confirm or reconnect.
          • Use the event system (?) to emit kernel state?
        • (3) in jupyter-server, we should use a bit more discipline. Instead of opening individual sockets through the kernel manager API, we should open a single kernel client server-side. This opens a fixed set of ZMQ channels. All client->server->kernel connections, e.g. kernel websockets, should use this single kernel client.
          • Also, stop nudging the kernel for state. Just ask the server using the kernel state tracking from (2).

@Zsailer
Copy link
Member Author

Zsailer commented Jun 6, 2024

June 6th, 2024

Name affiliation GitHub username
Vidar T Fauske JP Morgan Chase @vidartf
David Brochart QuantStack @davidbrochart
Steve Silvester MongoDB @blink1073
Zach Sailer Apple @Zsailer
Johan Mabille QuantStack
Omar Jarjur Google @ojarjur

Agenda

  • Zach

    • Follow up on "next-generation" kernel API
      • work in progress: https://github.com/Zsailer/nexgen-kernel-manager
      • Improvements made:
        • tracks kernel lifecycle state and execution state server-side.
        • uses a single kernel client (thus, single set of ZMQ channels) to communicate with the kernel. No need to open ZMQ sockets outside of this client.
        • uses a completely native asyncio approach to poll messages from the kernel, dropping the tornado IOLoop and ZMQStream logic.
        • simplifies the websocket connection logic
          • removes all nudging logic in the websocket handler, since the kernel manager owns this now.
          • the WS handle registers itself as a listener on the kernel client
          • the websocket can connect, even if the kernel is busy. (I think) this eliminates the necessity for "pending" kernels. Every kernel can be in a "pending" state.
      • how does this affect Omar's PR, which is trying to get an accurate execution_state on the server: Improve the busy/idle execution state tracking for kernels. jupyter_server#1429
        • We should proceed with reviewing this PR, if it doesn't increase our API service.
        • We should be able to simplify this PR but just "watching" the shell channel status messages.
        • Can we assume shell messages get queued?
          • If no, we might need to additional tracking of parent message ID
          • If yes, just tracking control channel should be enough.

  • Steve

@3coins
Copy link

3coins commented Jun 20, 2024

June 13th, 2024

Name affiliation GitHub username
Vidar T Fauske JP Morgan Chase @vidartf
Steve Silvester MongoDB @blink1073
Zach Sailer Apple @Zsailer
David Brochart QuantStack @davidbrochart
Johan Mabille QuantStack
Ian Thomas QuantStack @ianthomas23

Agenda

@3coins
Copy link

3coins commented Jun 22, 2024

June 20th, 2024

Name affiliation GitHub username
Piyush Jain AWS @3coins
Vidar T Fauske JP Morgan Chase @vidartf
Zach Sailer Apple @Zsailer
Andrii Ieroshenko AWS @andrii-i
Afshin T. Darian @QuantStack @afshin
Mike Krassowski Quansight @krassowski

Agenda

  • Demo of Parameterized Kernel Specs JEP

    • Context:

    • Vidar - Needs a flag to turn the save/load from notebook feature off/on, could cause shell injection attacks.

    • Zach - Separate the saving of kernel parameters in notebook to a separate kernel spec file, provide a save option.

      • Should the save kernel spec be a separate feature?
      • I don't think embedding detailed info about kernel runtime/environment in the notebook document is good broad solution. The moment that the notebook document leaves the current server, e.g. shared with a colleague, those parameters are essentially useless. You have to send the kernel + kernelspec.
      • In my experience doing something similar, it was better to save these details as a static (i.e. not parameterized) kernelspec.

  • Mike

    • securing config
      • A config that user can't read, example: imagine a billing document that can be saved in settings, but should not be accessed by the user.
        • Possible solution: Make file readable only by the server user in OS, would require elevating privileges of Jupyter server, which might not be ideal.
        • Alternate solution: Running extensions in a separate container than the main server, proxying the calls.
        • Nick/Zach: Comprehensive solution to isolate access with capability based model.

  • Nick

    • Demo of jupyter-speedscope extension to work with the speedscope profiler in the notebook

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@3coins @Zsailer