When scap starts, depool proxies. After it completes/it fails, repool those nodes again. This will avoid or mitigate performance problems (and even unexpected unavailability) while proxies are being used for syncronization by several nodes at the same time, reducing its available CPU, disk and network bandwidth for regular mediawiki tasks.
Description
Description
Revisions and Commits
Revisions and Commits
rMSCA Scap | |||
Restricted Differential Revision | rMSCA6c36daed0976 Create a wrapper around conftool for our pooling/depooling needs |
Status | Subtype | Assigned | Task | ||
---|---|---|---|---|---|
Resolved | Legoktm | T67289 Use semantic versioning scheme for WMF (all) releases | |||
Resolved | • GWicke | T102550 Use semantic versioning for services (for consistency with mediawiki core) | |||
Resolved | • mmodell | T94620 [EPIC] The future of MediaWiki deployment: Tooling | |||
Open | Feature | None | T22085 [scap] Local sync script on any individual server should be atomic | ||
Resolved | None | T125629 Depool proxies temporarily while scap is ongoing to avoid taxing those nodes | |||
Resolved | None | T104352 Make scap able to depool/repool servers via the conftool API | |||
Resolved | Joe | T73212 Make it possible to quickly and programmatically pool and depool application servers | |||
Resolved | None | T115899 Move scap target configuration to etcd | |||
Resolved | Joe | T163565 Install conftool on deployment masters |