There is a gitlab.rb sidekiq enable option
What does this MR do?
The gitlab.rb
template is missing sidekiq['enable']
(defaulting to true
)
A customer asked me to advise them about splitting Sidekiq out to separate servers, and is using explicit enable [true|false] settings rather than roles.
So, I needed to test if sidekiq['enable']
exists.
Seems it does, so let's add it to the template.
false
* ruby_block[disable sidekiq] action run[2023-07-13T20:38:12+01:00] INFO: ruby_block[disable sidekiq] called
- execute the ruby block disable sidekiq
--- /var/opt/gitlab/prometheus/prometheus.yml 2023-03-02 08:25:07.976240138 +0000
+++ /var/opt/gitlab/prometheus/.chef-prometheus20230713-22961-pxyhpr.yml 2023-07-13 20:38:14.889160271 +0100
@@ -43,16 +43,6 @@
regex: 127.0.0.1:(.*)
replacement: localhost:$1
target_label: instance
-- job_name: gitlab-sidekiq
- static_configs:
- - targets:
- - 127.0.0.1:8082
- relabel_configs:
- - source_labels:
- - __address__
- regex: 127.0.0.1:(.*)
- replacement: localhost:$1
- target_label: instance
true
* link[/opt/gitlab/service/sidekiq] action create[2023-07-13T20:39:09+01:00] INFO: link[/opt/gitlab/service/sidekiq] created
- create symlink at /opt/gitlab/service/sidekiq to /opt/gitlab/sv/sidekiq
* ruby_block[wait for sidekiq service socket] action run[2023-07-13T20:39:13+01:00] INFO: ruby_block[wait for sidekiq service socket] called
- execute the ruby block wait for sidekiq service socket
--- /var/opt/gitlab/prometheus/prometheus.yml 2023-07-13 20:38:14.889160271 +0100
+++ /var/opt/gitlab/prometheus/.chef-prometheus20230713-23818-69q95t.yml 2023-07-13 20:39:15.465361810 +0100
@@ -43,6 +43,16 @@
regex: 127.0.0.1:(.*)
replacement: localhost:$1
target_label: instance
+- job_name: gitlab-sidekiq
+ static_configs:
+ - targets:
+ - 127.0.0.1:8082
+ relabel_configs:
+ - source_labels:
+ - __address__
+ regex: 127.0.0.1:(.*)
+ replacement: localhost:$1
+ target_label: instance
Nice!
Related issues
Author's checklist
-
Consider taking the GitLab Technical Writing Fundamentals course -
Follow the: -
When ready for review, MR is labeled "~workflow::ready for review" per the Distribution MR workflow
If you are only adding documentation, do not add any of the following labels:
~"feature"
~"frontend"
~"backend"
~"bug"
~"database"
These labels cause the MR to be added to code verification QA issues.
Review checklist
Documentation-related MRs should be reviewed by a Technical Writer for a non-blocking review, based on Documentation Guidelines and the Style Guide.
-
If the content requires it, ensure the information is reviewed by a subject matter expert. - Technical writer review items:
-
Ensure docs metadata is present and up-to-date. -
Ensure the appropriate labels are added to this MR. - If relevant to this MR, ensure content topic type principles are in use, including:
-
The headings should be something you'd do a Google search for. Instead of Default behavior
, say something likeDefault behavior when you close an issue
. -
The headings (other than the page title) should be active. Instead of Configuring GDK
, say something likeConfigure GDK
. -
Any task steps should be written as a numbered list. - If the content still needs to be edited for topic types, you can create a follow-up issue with the docs-technical-debt label.
-
-
-
Review by assigned maintainer, who can always request/require the above reviews. Maintainer's review can occur before or after a technical writer review. -
Ensure a release milestone is set.