[Pools] Add Support for Autoscaling#8483
Conversation
|
/smoke-test -k test_pool_autoscaling --kubernetes |
Summary of ChangesHello @lloyd-brown, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request introduces a significant enhancement to service pools by enabling queue-length-based autoscaling. This allows service pools to automatically adjust their worker count based on the number of pending jobs, improving resource utilization and responsiveness. The changes involve adding a new autoscaler implementation, extending service configuration options, updating YAML parsing and serialization, and introducing a database utility to monitor job queues. Highlights
🧠 New Feature in Public Preview: You can now enable Memory to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console. Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
There was a problem hiding this comment.
Code Review
This pull request introduces a queue-length-based autoscaler for service pools. The changes are extensive, touching state management, autoscaler logic, service specification, configuration schemas, and tests. My review focuses on correctness, maintainability, and consistency. I've identified a few issues: a potential bug in how pending jobs are counted, duplicated code in the new autoscaler, inconsistencies in schema validation, and a minor bug in a test helper function. Overall, the feature is well-implemented with good test coverage, and the suggested changes should improve its robustness and maintainability.
|
/smoke-test -k test_pool_autoscaling --kubernetes |
cg505
left a comment
There was a problem hiding this comment.
Core functionality looks good, but there's a lot of code that I think could be cleaned up, especially the SkyServiceSpec.from_yaml_config which seems way too complicated for what it's doing
8e514fe to
972340e
Compare
|
/smoke-test -k test_pool_autoscaling --kubernetes |
972340e to
9f1c9c3
Compare
|
/smoke-test -k test_pool_autoscaling --kubernetes |
cg505
left a comment
There was a problem hiding this comment.
Thanks for the fixes! The broad strokes look good now, just a few minor fixes
138dd72 to
d9eb5b9
Compare
|
/smoke-test -k test_pool_autoscaling --kubernetes |
|
/smoke-test -k test_pools --kubernetes |
|
/smoke-test -k test_pools --kubernetes |
|
/smoke-test -k test_update_workers --kubernetes |
cg505
left a comment
There was a problem hiding this comment.
Thanks for updating everything! LGTM at this point!
Co-authored-by: Christopher Cooper <christopher@cg505.com>
|
/smoke-test |
|
/smoke-test -k test_pools --kubernetes |
Add documentation for the new autoscaling support in pools (PR #8483). - Add "Autoscaling" section covering min_workers/max_workers YAML syntax - Document all autoscaling options: queue_length_threshold, upscale_delay_seconds, downscale_delay_seconds - Explain scale-to-zero behavior (min_workers: 0) - Document how to combine a fixed baseline with autoscaling bounds - Remove "Autoscaling" from the Coming Soon admonition Generated with [Claude Code](https://claude.ai/code) via [Happy](https://happy.engineering) Co-Authored-By: Claude <noreply@anthropic.com> Co-Authored-By: Happy <yesreply@happy.engineering>
* [Docs] Document pool autoscaling feature Add documentation for the new autoscaling support in pools (PR #8483). - Add "Autoscaling" section covering min_workers/max_workers YAML syntax - Document all autoscaling options: queue_length_threshold, upscale_delay_seconds, downscale_delay_seconds - Explain scale-to-zero behavior (min_workers: 0) - Document how to combine a fixed baseline with autoscaling bounds - Remove "Autoscaling" from the Coming Soon admonition Generated with [Claude Code](https://claude.ai/code) via [Happy](https://happy.engineering) Co-Authored-By: Claude <noreply@anthropic.com> Co-Authored-By: Happy <yesreply@happy.engineering> * Update docs/source/examples/pools.rst Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com> * [Docs] Add pool section to YAML spec reference (#8927) [Docs] Add pool section to task YAML spec reference Adds documentation for the pool top-level field and its autoscaling sub-fields (workers, min_workers, max_workers, queue_length_threshold, upscale_delay_seconds, downscale_delay_seconds) to the YAML spec reference, matching the existing SkyServe Service section format. * [Docs] Fix undefined label reference in pool yaml spec Change :ref: target from 'job-pool' to 'pool' to match the label defined in pools.rst, fixing the doc build warning. --------- Co-authored-by: Ubuntu <azureuser@agent-vm-78fa7c50-9021-0.cdqox45qxbquxbrpbcn2wku0eg.bx.internal.cloudapp.net> Co-authored-by: Claude <noreply@anthropic.com> Co-authored-by: Happy <yesreply@happy.engineering> Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com>
This PR adds support for autoscaling pools (even down to 0). The user can now specify in their yaml the max and min number of workers and the target queue length. We introduce a QueueLengthAutoscaler which scales up when the number of pending jobs is more than the queue length and down when it's less.
We also add logic to this autoscaler to prevent us from scaling down past the number of running jobs so that we don't cancel jobs when autoscaling. The downside of this is that if there is a large backlog of jobs we may fail to scale down since a worker that should be scaled down quickly picks up another job. But fixing this would require us to have a new replica status that says a replica should terminate after job completion and the logic there is hairy and I haven't figured it out yet so this is a first cut.
We added some smoke tests to ensure we scale up when our queue length is lower and to make sure we can scale down to zero.
This also address issue #8395
EDIT: Had some discussion with @cg505 about the current algorithm and discussed some changes we should make here and some future work.
The queue length autoscaler as is will scale rather slowly. We inherit the hysteresis autoscaler which by default scales only once every 300 seconds and the autoscaler only scales up by 1 each period. To fix this we could implement some strategy like scaling up based on some factor of the queue length. Setting this factor is tricky, if you set it too high then you might end up setting the number of workers to the max unless the queue is empty.
Since we expect that the chief concern is good utilization (i.e. not wasting workers that are up) we think the current approach is good enough. One thing we should change before the PR is merged that also pertains to utilization is quickly reducing the number of workers to 0 when there are no pending jobs.
In a subsequent PR we will work on a scaling based approach.
Tested (run the relevant ones):
bash format.sh/smoke-test(CI) orpytest tests/test_smoke.py(local)/smoke-test -k test_name(CI) orpytest tests/test_smoke.py::test_name(local)/quicktest-core(CI) orpytest tests/smoke_tests/test_backward_compat.py(local)