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