The source project of this merge request has been removed.
Allow sidekiq to react to becoming a Geo primary or secondary without a restart
What does this MR do?
Sidekiq runs a set of cron jobs. This set differs according to whether the node is a Geo primary or secondary, or if Geo is disabled. Previously, the state was determined once, when sidekiq was started. Now, we add a cron job that runs the same logic each minute.
To reduce churn, the enable/disable logic now only changes jobs if they are in the wrong state.
Are there points in the code the reviewer needs to double check?
The post-deployment migration is a bit of a cheat, but we need to re-enable these jobs as a one-time operation (so they can be manually disabled later if the administrator so desires).
Why was this MR needed?
In HA scenarios, ensuring every node is restarted in a timely manner is not easy. Much better to respond to changes without a restart being required.
Screenshots (if relevant)
Does this MR meet the acceptance criteria?
-
Changelog entry added, if necessary -
Documentation created/updated -
Tests added for this feature/bug -
Has been reviewed by Backend -
Conform by the merge request performance guides -
Conform by the style guides -
Squashed related commits together -
Internationalization required/considered -
If paid feature, have we considered GitLab.com plan and how it works for groups and is there a design for promoting it to users who aren't on the correct plan
What are the relevant issue numbers?
Closes #4048 (closed)
Edited by Nick Thomas