-
-
Notifications
You must be signed in to change notification settings - Fork 322
Split server up into manager + executor paradigm #2597
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
Conversation
4bf856d
to
86924a1
Compare
New issue discovered: Video iteration can fail/freeze when FFMPEG outputs to stdout. I currently have no idea how to resolve this and i would consider it a blocker for merging. |
* Make `DependencyInfo` a data class to simplify code * Minor bug
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.
Feel free to merge when you think this is ready. The general approach and architecture look good. If it works, then it's ready.
A draft PR for what we've been discussing on Discord. Not ready to actually be merged yet.
This separates the server into two parts: The manager server which handles dependency tracking and installation, and the executor server, which handles package/node loading.
This is necessary to allow us to update and uninstall dependencies on the backend, due to the to-be-modified dependencies needing to not be loaded in python. With this new paradigm, the executor server can be killed while the manager server can stay open and manage the dependencies properly, then start the executor server back up. This also would allow us to implement the "timeout killing" feature backend-side rather than frontend-side, decoupling that even more.
The manager server acts as a proxy for most requests, while other requests are handled by it.
This does not actually implement the aforementioned dependency management and executor-killing features. Those will be tackled in a separate future PR once this one is finalized. This PR is an attempt to mimic current behavior as closely as possible.
Before being considered ready, this PR needs to be heavily tested, including through brand-new installs, to ensure no regressions.
TODO:
requests
dependency change