Skip to content

Cap maximum Docker Machine provisioning rate

What does this MR do?

This implements a limit on the maximum concurrency for the number of machines being provisioned by Docker Machine. The limit is on a per-runner basis though, so in theory it is possible that if all runners are scaling out at once the same rate-limit can occur.

Once this has been implemented, the subsequent fix was with the allocation of provisioned runners to new jobs. Previously, if there are no free instances, jobs will wait for a runner to be provisioned before running. Now, if another runner is made free while one is being provisioned, the newly-freed runner will pick up the job.

Why was this MR needed?

This should more thoroughly fix #3296 (closed), which somewhat prevents #3424 (closed).

Based on the limitations of docker+machine, @brendan votes that this MR, when accepted, closes #3424 (closed)

Are there points in the code the reviewer needs to double check?

This should work with no changes to config.toml; I'm not sure how to implement tests for this.

This is concurrent code, checks for deadlocks and race conditions welcome.

Does this MR meet the acceptance criteria?

  • Documentation created/updated
  • Added tests for this feature/bug
  • In case of conflicts with master - branch was rebased

What are the relevant issue numbers?

Closes #3424 (closed)

Edited by Marcel Amirault

Merge request reports