Skip to content

GitLab Next

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
gitlab-runner
gitlab-runner
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 2,099
    • Issues 2,099
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
    • Iterations
  • Merge requests 208
    • Merge requests 208
  • Requirements
    • Requirements
    • List
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
    • Test Cases
  • Operations
    • Operations
    • Incidents
    • Environments
  • Packages & Registries
    • Packages & Registries
    • Container Registry
  • Analytics
    • Analytics
    • CI/CD
    • Code Review
    • Insights
    • Issue
    • Repository
    • Value Stream
  • Members
    • Members
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • GitLab.org
  • gitlab-runnergitlab-runner
  • Merge requests
  • !1038

Merged
Created Sep 28, 2018 by Joel Low@lowjoelContributor0 of 3 tasks completed0/3 tasks

Cap maximum Docker Machine provisioning rate

  • Overview 133
  • Commits 9
  • Pipelines 50
  • Changes 7

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 Jul 09, 2020 by Marcel Amirault
Assignee
Assign to
Reviewer
Request review from
13.6
Milestone
13.6 (Past due)
Assign milestone
Time tracking
Source branch: maximum-machine-growth-rate