Update Sidekiq chart queues based on routingRules

What does this MR do?

Since we updated default routing rules in Rails gitlab-org/gitlab!97908 (merged), now we need to update the default queues listened by Sidekiq. This MR updates SIDEKIQ_QUEUES based on the following condition:

• Defaults to 'default,mailers' unless global.appConfig.sidekiq.routingRules is set.
• Generate SIDEKIQ_QUEUES based on the queues listed in routingRules if set.
• User can still customize SIDEKIQ_QUEUES in the Sidekiq chart per pods values (Existing condition)

Related issues

• gitlab-com/gl-infra/scalability#1930
• gitlab-com/gl-infra/scalability#1491

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
• When ready for review, MR is labeled "~workflow::ready for review" per the Distribution MR workflow

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 omnibus-gitlab 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.

added maintenancescalability typemaintenance workflowin dev labels

assigned to @marcogreg

added 1 commit

• ddc222db - Update Sidekiq chart queues based on routingRules

Compare with previous version

	1 Warning
	Please check the QA job and compare with builds on master. If no new failures are reported in QA job, add 'QA:verified' label.

1 Message

Please add the workflowready for review label once you think the MR is ready to for an initial review. If from a community member, ask that the Community contribution label be added as well. 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 Maintainers

Generated by Danger

added groupdistribution label

added devopssystems sectioncore platform labels

changed milestone to %15.5

mentioned in merge request gitlab-org/omnibus-gitlab!6289 (closed)

marked this merge request as ready

removed workflowin dev label

added workflowready for review label

mentioned in epic gitlab-com/gl-infra&596 (closed)

mentioned in epic gitlab-com/gl-infra&148

added workflowin review label and removed workflowready for review label

requested review from @jayo

mentioned in merge request gitlab-org/gitlab!100392 (merged)

@marcogreg this looks good - I had one question above on the append for "mailers".

The other question I have if this should wait on gitlab-org/gitlab!100392 (merged) getting merged - or that we just need to make sure both of these merge in 15.5 so that the migration is present to handle the <15.4 -> 15.5 upgrades per your comment here

Thanks for the review!

Yes, ideally gitlab-org/gitlab!100392 (merged) at least should be merged together. But I'm not sure if gitlab-org/gitlab!100392 (merged) would cut it for the %15.5 by 17th Oct. There is a risk of losing jobs if this charts MR gets merged first on an earlier release than the migration MR.

Should we just include this MR on %15.6 instead to be safe for now? Does marking this MR on %15.6 ensure it won't be in %15.5 release, even though it's already merged?

I believe that to be the case, but I don't know for absolute sure at the moment.

@mnielsen Can you take a look at this as maintainer? And do you know if the release process for the Charts respects the milestone assigned?

Test Notes

Functionally I verified that this set SIDEKIQ_QUEUES to default,mailers for the Sidekiq deployment in a new installation, upgrades from 6.4.2 to the branch, and upgrades from 6.3.4 to the branch ( observing that new workers were created in the default queue using the sidekiq monitoring in the admin UI ).

I also set routing rules (with a spurious "condition"), observing that SIDEKIQ_QUEUES would be set to the values of the routingRules as expected (and un-duplicated via the last commit).

global:
  appConfig:
    sidekiq:
      routingRules:
        - ["tag1", "merge"]
        - ["tag2", "mailers"]
        - ["tag3", "default"]

And do you know if the release process for the Charts respects the milestone assigned?

I don't believe Milestone factors in for release-tools, just what's been merged. Correct me if I'm wrong @WarheadsSE.

Milestones do not truly factor in when cutting a new minor release. Only after that, do the milestones come into play, and where Pick into 15.5 type labels come into play.

I'll set this milestone for %15.6 and we can revisit then

I see gitlab-org/gitlab!100392 (merged) merged last week, are we comfortable moving forward with this for %15.6 still @marcogreg?

Thanks for the ping @mnielsen.

Unfortunately, we can't move forward with this MR. Full context in gitlab-com/gl-infra/scalability#1991.

TLDR: We reverted gitlab-org/gitlab!97908 (merged) in 15.6. That change caused performance regression in Sidekiq for self-managed in 15.4. Because this MR depends on the Rails MR also, we can't automate the queue_groups generation.

So, I'm closing this MR. Thanks for all the help!

And sorry, I missed out on updating this MR!

No worries, thanks!

added 1 commit

• bcd28d80 - Deduplicate mailers queue

Compare with previous version

approved this merge request

requested review from @mnielsen

added 1 commit

• 4bd8cdf9 - Move default queues to Sidekiq chart values.yaml

Compare with previous version

removed milestone %15.5

marked the checklist item MR has a green pipeline on GitLab.com as completed

marked the checklist item When ready for review, MR is labeled "~workflow::ready for review" per the Distribution MR workflow as completed

changed milestone to %15.6

mentioned in merge request gitlab-org/build/CNG!1109 (closed)

added 1 commit

• 33c18ea5 - Revert changes to root values.yaml

Compare with previous version

mentioned in merge request gitlab-org/gitlab!100823 (merged)

marked the checklist item Equivalent MR/issue for omnibus-gitlab opened as completed

marked the checklist item 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. as completed

mentioned in merge request gitlab-org/gitlab!103001 (closed)

closed