Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Replace adjustments with min/max for scale in and out #12
Currently we have scale-in-adjustment and cooldown, but when I went to extend this to a scale-out adjustment I realized that there are two distinct use cases, a minimum bound and a maximum bound for each scaling direction.
For scale-in, you might want to slow down scale-in, for which you'd set a
For scale-out, you might want to have faster scale-out, so you set a
I also implemented a
@etaoins I'd love your feedback on
etaoins left a comment •
I think it is possible to merge the scale-in and scale-out cases. The trick is that because scale-in params are negative the largest possible scale-in value is actually the minimum value mathematically while the smallest possible is the maximum value. I don't think we'd want to expose this in the name of the parameters so we'd have to flip them in the negative case when we built the
MaxAdjustment: *scaleInMinAdjustment, MinAdjustment: *scaleInMaxAdjustment,
We'd also need to change some of the
While that would end up being less code I'm leaning towards that being too clever. The current code is pretty explicit and has tailored log messages for each case.
What if rather than min/max or adjustment we went with
That would handle the two main uses cases:
That seems like it would work better with build queues that have wildly varying load (eg a corporate build queue might have 20 jobs during the day and only a couple overnight). Makes sense to making the scaling scalable
We’d have to make sure we wouldn’t hit an asymptote when scaling down. For example, if we’re scaling down by 25% with only 3 agents we’d need to make sure we eventually scale to 2 instead of always rounding to 3.