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 builds and interactive sessions events to orchest-api
(notifications)
#950
Add jupyter builds and interactive sessions events to orchest-api
(notifications)
#950
Conversation
orchest-api
orchest-api
orchest-api
(notifications)
This allows to keep track of what subset of the pipeline nodes where used for the interactive run.
The constraint already exists under the form of a FK to pipelines, given our db schema and the fact that we are using single table inheritance this constraint is not compatible in some edge cases and redundant in others.
Given that pretty much all session related calls needs a project and pipeline UUID it clearly shows that sessions are a events._register_interactive_session_service_restarted(
project_uuid, pipeline_uuid
) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
Alright sounds good 👍 |
…ts-to-orchest-api Add project and pipeline events to `orchest-api` (notifications)
…-api Add environment created/delete events to `orchest-api` (notifications)
…orchest-api Move job_update event to the `orchest-api` (notifications)
…thub.com:orchest/orchest into improv/add-interactive-runs-event-to-orchest-api
…t-to-orchest-api Add interactive pipeline run events to `orchest-api` (notifications)
…active-session:pipeline-run:*
…hest into improv/add-builds-events-to-orchest-api
Description
Adds support for jupyter builds and interactive sessions events to the
orchest-api
, these events can now be subscribed to and are now part of the analytics module.@yannickperrenet one point of discussion for me here would be about the conceptual nesting of events, i.e.
project:interactive-session:started
vs a possibleproject:pipeline:interactive-session:started
. I have currently gone for the former but I have no strong feelings about it (not even mild tbh), would be good to reach a consensus pre-merge to avoid breaking schemas later.Checklist
models.py
I have performed the appropriate databasemigrations (refer to
scripts/migration_manager.sh
).