Route invoke requests through planner #330
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
0a40cd5 to
46dc9af
Compare
Codecov Report
@@ Coverage Diff @@
## main #330 +/- ##
==========================================
+ Coverage 82.61% 82.66% +0.05%
==========================================
Files 98 98
Lines 7861 7874 +13
==========================================
+ Hits 6494 6509 +15
+ Misses 1367 1365 -2
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
In this PR we move the HTTP endpoint to request function executions, and their execution status, from the worker to the planner. This means that the worker's endpoint doesn't serve any more requests.
I will ompletely remove the worker endpoint in a separate PR, as the endpoint (in
SIGNALmode) is what keeps the worker process (i.e. inpool_runner) in the foreground, so it is a rather big change.In this PR the planner blindly forwards requests to a registered worker picked at random. In subsequent PRs the planner will keep track of in-flight requests, and will make scheduling decisions. Doing so keeps this PR simple, as it already has a lot of consequences downstream (in terms of the interaction with a running cluster, and the k8s/compose deployments).