Skip to content
New issue

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

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

Already on GitHub? # 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.

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
# for free to join this conversation on GitHub. Already have an account? # to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants