Skip to content

Add 'use_wrapper' setting to Gitaly

Will Chandler (ex-GitLab) requested to merge wc/unwrap-gitaly into master

What does this MR do?

Gitaly is in the process of implementing a write-ahead log (WAL) for git operations, which will provide significant benefits for resiliance and scalability.

This model requires that we have only one Gitaly process running at a time. However, our current upgrade method keeps the old and new Gitaly processes running in parallel for an period of time defined by the administrator.

The gitaly-wrapper binary is used by Omnibus to provide a stable pid to runit and sets the GITALY_UPGRADES_ENABLED environment variable that causes Gitaly to perform upgrades with concurrent processes.

To prepare for the deployment of Gitaly's WAL architecture, add a new gitaly['use_wrapper'] option which allows admins to execute Gitaly without the gitaly-wrapper binary so that there is never more than one Gitaly process running at once. This is enabled by default, admins must opt into the new behavior.

Without the wrapper, sending SIGHUP to Gitaly will cause momentary service interruptions for git clone operations, ~300ms in our benchmarks. Read-only web requests will retry automatically for outages lasting up to 750ms and will handle the upgrade gracefully.

We retain the wrapper for Praefect as this will remain compatible with running concurrent processes.

Related issues

Checklist

See Definition of done.

For anything in this list which will not be completed, please provide a reason in the MR discussion.

Required

  • MR title and description are up to date, accurate, and descriptive.
  • MR targeting the appropriate branch.
  • Latest Merge Result pipeline is green.
  • When ready for review, MR is labeled "~workflow::ready for review" per the Distribution MR workflow.

For GitLab team members

If you don't have access to this, the reviewer should trigger these jobs for you during the review process.

  • The manual Trigger:ee-package jobs have a green pipeline running against latest commit.

Expected (please provide an explanation if not completing)

  • Test plan indicating conditions for success has been posted and passes.
  • Documentation created/updated.
  • Tests added.
  • Integration tests added to GitLab QA.
  • Equivalent MR/issue for the GitLab Chart opened.
  • Validate potential values for new configuration settings. Formats such as integer 10, duration 10s, URI scheme://user:passwd@host:port may require quotation or other special handling when rendered in a template and written to a configuration file.
Edited by Clemens Beck

Merge request reports