Using dsh group lists for deployment targets is lamesauce. Let's use etcd.
Description
Description
| 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 | fgiunchedi | T80395 Update dsh node groups from puppet | |||
| Resolved | None | T115899 Move scap target configuration to etcd |
Event Timeline
Comment Actions
Do we get anything useful out of this? Or is this task just because it's the cool thing to do?
Comment Actions
We get to kill the entire dsh module (remove cruft) which is not used anymore except for this.
Comment Actions
If we've already got the list of hosts in etcd (for pybal) then it's duplication of config for one thing. I think it's been said elsewhere (and better) by others, but puppet isn't great for managing large lists of things like this that are subject to change on short notice.
Comment Actions
We ended up generating the dsh lists in production from etcd, which is ok as a solution without asking scap to know about its details. I think we can close this ticket.