Change Gitlab::SidekiqStatus to use SharedState redis rather than Queues (sidekiq)
With https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/redis/queues_metadata.rb available, we can move sidekiq status to QueuesMetadata
and avoid running a post-deployment migration for users. This greatly simplifies our release and reasoning about Sidekiq-related redis:
-
Gitlab::Redis::Queues
to be used bySidekiq.redis
only -
Gitlab::Redis::QueuesMetadata
to be used to house Gitlab-context-specific sidekiq data like sidekiq status and jobs deduplication
For gitlab.com, we use separate Redises for the 2 classes above but SM-users will likely use the same Redis unless specified otherwise.
Click to show past context
From #867 (comment 510109361):
To move to any multi-cluster sidekiq deployment, be that per-zone clusters in k8s or some other design, Gitlab::SidekiqStatus needs to use a a global shared Redis rather than the implied one per-cluster. Otherwise any use of the methods in that class to introspect what's running will only see data for the specific sidekiq cluster available where that code is running. We use this commonly to detect stuck jobs e.g. https://gitlab.com/gitlab-org/gitlab/-/blob/master/app/workers/stuck_export_jobs_worker.rb#L30 (and many others) which needs to have a global view of the entire GitLab deployment.
The actual code change is largely trivial; migration for a running system is likely to be challenging.