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

Add Jupyter Events and emit events from the Kernel Manager #832

Merged
merged 9 commits into from
Sep 13, 2022

Conversation

Zsailer
Copy link
Member

@Zsailer Zsailer commented Sep 12, 2022

This requires a release of Jupyter Events... done 👍

  • Adds an event schema for the KernelManager
  • Adds events to various methods in the default KernelManager implementation.
  • Adds tests to the kernelmanager's lifecycle unit test to ensure events are emmitted.

@ccordoba12
Copy link
Contributor

This looks like a major change, so hopefully for Jupyter-client 8, right?

@Zsailer
Copy link
Member Author

Zsailer commented Sep 12, 2022

@ccordoba12, yeah, I think that's fair. This adds an additional dependency, jupyter_events, which I think warrants a major release.

@blink1073
Copy link
Contributor

Good call @ccordoba12, I've opened #833

@blink1073 blink1073 added this to the 8.0 milestone Sep 12, 2022
kernel_id:
oneOf:
- type: string
- type: "null"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks good @Zsailer - just have one question.

Is this in anticipation of supporting other actions, because all of the currently defined actions fire with a non-None kernel_id? If we retained that approach, we could then apply a format or pattern, allowing only UUID formats (and remove the oneOf and null). This might allow event consumers to have an easier experience as well.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

because all of the currently defined actions fire with a non-None kernel_id?

I don't think start_kernel or pre_start_kernel methods strictly require a kernel_id to start, right? This logic seems to suggest that if None is provided, it creates a uuid on the fly.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That is correct (on both counts; non-required kernel_id and auto-create logic). The provisioners should have access to the kernel-id from the get-go so they can do indexing, etc. as necessary.

tests/test_manager.py Outdated Show resolved Hide resolved
Copy link
Contributor

@blink1073 blink1073 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, thanks!

@blink1073 blink1073 merged commit a6db20d into jupyter:main Sep 13, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants