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,106
    • Issues 2,106
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
    • Iterations
  • Merge requests 207
    • Merge requests 207
  • 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
  • !383

Merged
Created Nov 10, 2016 by Janis Meybohm@jayme-githubContributor3 of 4 tasks completed3/4 tasks

Kubernetes termination grace period

  • Overview 5
  • Commits 2
  • Pipelines 3
  • Changes 3

What does this MR do?

Add a configuration option for the termination grace period of build pods.

Why was this MR needed?

When a build is finished (e.g. Pod is deleted) Kubernetes will send SIGTERM to applications in the containers of the Pod, which can be handled in order to effect graceful termination. SIGKILL is sent a configurable number of seconds later if the application does not terminate sooner (defaults to 30 seconds, controlled by spec.terminationGracePeriodSeconds).

Lots of fast, parallel builds will leave Pods of finished builds behind for 30 seconds, blocking cluster resources. With a lower (or even 0) terminationGracePeriodSeconds, Pods of finished builds will be cleaned up immediately.

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

@munnerz could you give me a hint on how to integrate that into the existing tests?

Does this MR meet the acceptance criteria?

  • Documentation created/updated
  • Tests
    • Added for this feature/bug
    • All builds are passing
  • Branch has no merge conflicts with master (if you do - rebase it please)

What are the relevant issue numbers?

Assignee
Assign to
Reviewer
Request review from
v1.10
Milestone
v1.10 (Past due)
Assign milestone
Time tracking
Source branch: kubernetes_terminationGracePeriodSeconds