Touching InitialiseSettings isn't scary. In fact, we should touch it more
- Group Reviewers
- rMSCAcbf17817c720: Remove concept of --no-touch / --beta-only-change
- Patch without arc
- git checkout -b D654 && curl -L https://phabricator.wikimedia.org/D654?download=true | git apply
@thcipriani Like we talked about last week. Really, this should do it on any scap pull now, regardless of what files are sync'd.
We might also want to touch the master at the very end of AbstractSync.main() after _after_cluster_sync() so future syncs don't think the targets are ahead of the masters (which seems like it could be an issue currently, regardless of this patch)
I agree with the idea that we should be touching IS after all the syncs that are meant to change things on the cluster; however, I think the --beta-only-change came out of a problem with how HHVM handled reclaiming TC cache space (i.e., exploding) T149872 and T103886#1401890 both talk about this.
The problem used to be HHVM could explode after innocuous syncs for files that didn't affect production, but were just being sync'd out because they were merged into mediawiki/config and no one wants to surprise the next deployer who pulls down changes they didn't make.
I haven't seen HHVM explode in a while, but T103886 is still open so I'm unclear the status of this failure mode. As of right now, I definitely use this to sync out beta-only changes fairly regularly, so it's at least useful to keeping the small amount of peace-of-mind I am able to cling to in place for whatever that's worth.
I would be curious if we had info on how often the flag is used vs. how often beta changes go out without the flag attached. I know I do it all the time if for no other reason than I forget the flag exists. scap sync-file foo 'No op beta-only' is pretty common. If those situations don't cause a cache rush, I'm not sure what we're still worried about (although you're right, T103886 remains open).