Default Sidekiq routing rules to queue per-worker
What does this MR do?
Due to the incident in gitlab-com/gl-infra/scalability#1991 (closed), in 15.6 (or 15.7) we want to set routing_rules
to [['*', nil]]
if routing_rules not already set and queue_groups only consists of *
s (can be multiple). We don't want to mess up with default routing_rules
, when users are touching the queue_groups
.
This change will protect users who have customized their queue_groups once we un-revert gitlab!103483 (merged) in 15.7 (or 15.8).
Related issues
Manual tests
Test Setup
This MR affects the resulting gitlab.yml
. I setup a local Ubuntu 20.04 VM (via multipass) to run some tests. Here's the steps:
- Setup VM
multipass launch lts --mem 8G --disk 20G --cpus 4
- Follow the instruction in the official GitLab download & installation.
- Setup environment to update cookbooks as in https://gitlab.com/gitlab-org/omnibus-gitlab/-/blob/master/doc/development/setup.md#get-the-source-of-omnibus-gitlab
Case 1: With default routing rules and default queue_groups
➜ ~ cat /var/opt/gitlab/gitlab-rails/etc/gitlab.yml | yq '.production.sidekiq.routing_rules'
null
Case 2: With default routing rules and multiple queue_groups all with '*'
➜ ~ cat /var/opt/gitlab/gitlab-rails/etc/gitlab.yml | yq '.production.sidekiq.routing_rules'
null
Case 3: With default routing rules and a queue_group != '*'
➜ ~ cat /var/opt/gitlab/gitlab-rails/etc/gitlab.yml | yq '.production.sidekiq.routing_rules'
- ["*", null]
Case 4: With routing rules set and default queue_groups
➜ ~ cat /var/opt/gitlab/gitlab-rails/etc/gitlab.yml | yq '.production.sidekiq.routing_rules'
- ["urgency=high", "urgent"]
- ["resource_boundary=cpu", "cpu_bound"]
- ["*", "default"]
Case 5: With routing rules set and queue_groups set
➜ ~ cat /var/opt/gitlab/gitlab-rails/etc/gitlab.yml | yq '.production.sidekiq.routing_rules'
- ["urgency=high", "urgent"]
- ["resource_boundary=cpu", "cpu_bound"]
- ["*", "default"]
Checklist
See Definition of done.
For anything in this list which will not be completed, please provide a reason in the MR discussion
Required
-
Merge Request Title, and Description are up to date, accurate, and descriptive -
MR targeting the appropriate branch -
MR has a green pipeline on GitLab.com -
Pipeline is green on dev.gitlab.org if the change is touching anything besides documentation or internal cookbooks -
trigger-package
has 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
Edited by Gregorius Marco