Make Gitaly internal API calls go through Workhorse
This will not only help improve observability of API calls made by Gitaly, but it will also enable Gitaly to download LFS files via the API to support archive downloads (gitlab#15079 (closed)).
Closes #5666 (closed)
On a single-node Omnibus instance, this results in this change:
* template[Create Gitaly config.toml] action create
- update content in file /var/opt/gitlab/gitaly/config.toml from 9f6716 to d47295
--- /var/opt/gitlab/gitaly/config.toml 2020-09-24 03:56:33.415040226 +0000
+++ /var/opt/gitlab/gitaly/.chef-config20200924-15565-1x6fwe4.toml 2020-09-24 04:00:53.517609937 +0000
@@ -36,7 +36,9 @@
dir = "/opt/gitlab/embedded/service/gitlab-shell"
[gitlab]
-url = 'http://127.0.0.1:8080'
+url = 'http+unix://%2Fvar%2Fopt%2Fgitlab%2Fgitlab-workhorse%2Fsocket'
+relative_url_root = ''
+
Merge request reports
Activity
added 1 commit
- 61e56656 - Extract internal API code into WebServerHelper
added 62 commits
-
61e56656...ec76b387 - 60 commits from branch
master
- 5aa17328 - Make Gitaly internal API calls go through Workhorse
- 537b1c40 - Extract internal API code into WebServerHelper
-
61e56656...ec76b387 - 60 commits from branch
changed milestone to %13.5
2 Warnings This merge request is missing any throughput labels. You’ve made some changes at the locations which contain user facing configuration.
That’s OK as long as you’re refactoring existing code and not adding any new
configuration. If you are adding new user facing configuration, consider adding
to gitlab.rb.template located in files/gitlab-config-template/gitlab.rb.template .
Otherwise, please consider adding the ~”feature::maintenance” label in that case.1 Message Please add the ~”workflow::ready for review” label once you think the MR is ready to for an initial review. Merge requests are handled according to the workflow documented in our handbook and should receive a response within the limit documented in our First-response SLO.
If you don’t receive a response, please mention
@gitlab-org/distribution
, or one of our Project MaintainersGenerated by
DangerEdited by 🤖 GitLab Bot 🤖added Observability groupdistribution labels
added 1 commit
- 9c16014a - Extract internal API code into WebServerHelper
assigned to @pursultani and unassigned @stanhu
The
Trigger:ce-package
job from pipeline https://gitlab.com/gitlab-org/omnibus-gitlab/-/pipelines/193786060 triggered https://gitlab.com/gitlab-org/build/omnibus-gitlab-mirror/-/pipelines/193853319 downstream.The
Trigger:qa-test
job from pipeline https://gitlab.com/gitlab-org/build/omnibus-gitlab-mirror/-/pipelines/193853319 triggered https://gitlab.com/gitlab-org/gitlab-qa-mirror/-/pipelines/193991047 downstream.The
gitlab-qa
downstream pipeline failed! .
mentioned in issue gitlab#15079 (closed)
Setting label(s) devopsenablement sectionenablement based on groupdistribution.
added devopssystems sectioncore platform labels
assigned to @ibaum and unassigned @pursultani
mentioned in merge request !4598 (merged)
I wonder if this affects SELinux: !4598 (merged). I think we should be okay since Gitaly and Workhorse are the same user, but it can't hurt to check.
- Resolved by Ian Baum
I think this looks good. I had the same results testing on Centos 8.
Thanks @stanhu!
mentioned in commit 48b6306a
added workflowstaging label
added workflowcanary label and removed workflowstaging label
mentioned in issue gitlab#258833 (closed)
added workflowproduction label and removed workflowcanary label
mentioned in issue #5348 (closed)
mentioned in commit gitlab-development-kit@85ade212
mentioned in merge request gitlab-development-kit!1643 (merged)
added workflowstaging-ref label and removed workflowproduction label
Due to an issue the workflowstaging-ref label was incorrectly applied to this merge request. Re-setting back to workflowproduction using
https://gitlab.com/gitlab-org/release-tools/-/merge_requests/1620
added workflowproduction label and removed workflowstaging-ref label