feat: maintain idle pool of runners #1038
Conversation
|
Is 1 a good default idle pool size? |
|
I think it would be best fix #1036 in this PR. |
| @@ -825,7 +826,7 @@ func (s *Service) reconcileRunners(ctx context.Context) (time.Duration, error) { | |||
| return 0, fmt.Errorf("%s: %w", "failed to get deployments needing reconciliation", err) | |||
| } | |||
|
|
|||
| totalRunners := 0 | |||
| totalRunners := s.config.IdleRunners | |||
There was a problem hiding this comment.
Haha wow that was easy 😂
Will give it a go |
|
It might be best just randomly generate them like it does in production. |
|
Ah, just did a an ever increasing version. Happy to switch it over to what we do in prod though if you prefer. Have the simpler ids been helpful in development up to now? Otherwise keeping it closer to prod seems like a better choice |
I think the idea was that it would make it slightly easier to debug, but I don't recall in practice ever relying on it or even caring. |
Adds
--idle-runnersarg to define how large the idle pool should be.Fixes #1036
Fixes #1030
Previous notes
Currently a draft because this PR makes #1036 more likely to be hit.
Before this change, killing all deployments would mean there are 0 runners, leading to no runner id collisions when you bring up more deployments
After this change, killing all deployments means that there will still be runners which will cause collisions if the idle runner ids aren't the lowest possible [
R00000000000000000000002000,R00000000000000000000004000... ]I've been testing with a hacky fix replacing line
bankend/controller/scaling/local_scaling.go:96to: