Repository navigation
Conversation
Add ballista.standalone.task_scheduling_policy (default pull-staged). With push-staged, the standalone scheduler pushes tasks and the standalone executor registers on a free gRPC port to receive them. The standalone scheduler now binds its listener before it is built and advertises its real address. Push-staged executors report task status to the endpoint each launch names, which was hardcoded to localhost:50050.
github-actions
Bot
added
the
documentation
This was referenced Oct 27, 2026
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
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.
Which issue does this PR close?
Part of #2652. This is the first of a series of smaller PRs split out of #2657 (pipelined execution).
Rationale for this change
A standalone (in-process) cluster always runs pull-staged. Pipelined execution needs push-staged scheduling, and its end-to-end tests run on standalone clusters, so the standalone cluster needs a push-staged option. That option is also useful by itself, for testing push-staged scheduling without starting separate processes.
Running push-staged in standalone mode exposed a bug. The standalone scheduler advertised the hardcoded endpoint
localhost:50050instead of the port it actually bound. Pull-staged executors never use that endpoint, but push-staged executors report task status to the endpoint each launch names.What changes are included in this PR?
ballista.standalone.task_scheduling_policy:pull-staged(the default, unchanged behavior) orpush-staged.new_standalone_scheduler_with_builderbinds its listener before it builds the scheduler, advertiseslocalhost:<port>, and uses the configured policy.push-staged,new_standalone_executor_from_buildertakes a free port for its task-launch gRPC server and starts throughexecutor_server::startup, instead of running the poll loop.setup_test_cluster_with_executors, starts a scheduler and several executors in one process.How are these changes tested?
ballista/client/tests/standalone_push_staged.rsruns a scan, an aggregate and a join on a push-staged standalone cluster, and on a push-staged scheduler with two executors. It compares each result with a pull-staged standalone cluster.Are there any user-facing changes?
There is one new setting,
ballista.standalone.task_scheduling_policy, documented in the config reference. The default behavior is unchanged.