Once T204022 is done and merged and deployed we can think about deploying the feature:
The feature should have a staged roll out, slowly ramping up the number of edits that the jobs are run for.
Throughout the time of the roll out metrics such as number of jobs in the queue etc should be monitored.
Throughout the rollout we also need to check the cache status and cache eviction rate, we probably can't fit results for all entities in the cache..
The job will only really take full effect when T204024 is also done persistently storing the data.
The config option was introduced in https://gerrit.wikimedia.org/r/#/c/463950/
The config options is `wgWBQualityConstraintsEnableConstraintsCheckJobsRatio`
Beta and test can probably be deployed quickly / in the same day (if everything goes fine).
wikidata.org should probably not proceed any faster than 1 increase per day.
Deployment List:
[x] beta wikidata 100% - 16th Jan 2019
[x] testwikidata 50% - 16th Jan 2019
[x] testwikidata 100% - 16th Jan 2019
[x] wikidata.org 1% - 16th Jan 2019
[x] wikidata.org 5% - 17th Jan 2019
[x] wikidata.org 10% - 22nd jan EU Morning 2019
[x] wikidata.org 25% - 22nd jan EU Morning 2019
[x] wikidata.org 40% - 1st Feb 2021
[x] wikidata.org 50% - 11th Feb 2021
[x] wikidata.org 60% - 12th Apr 2021
...
[] wikidata.org 100%
When deploying and expecting a rate of around 10 jobs per second ping #services
Dashboards:
- Job queue, https://grafana.wikimedia.org/d/000000400/jobqueue-eventbus?orgId=1&var-site=eqiad&var-type=constraintsRunCheck
- Wikidata Quality, https://grafana.wikimedia.org/d/000000344/wikidata-quality?orgId=1&from=now-24h&to=now
- Memcached, https://grafana.wikimedia.org/d/000000316/memcache?orgId=1&from=now-48h&to=now