Sat, May 19
Minor update: we noticed that the existing Travis CI configuration only requires one redis service, and we point both the task queue and score cache at the same server.
Fri, May 18
Wed, May 16
Here's a tiny bit of code I put together for P-R graphs specifically, https://github.com/adamwight/thresholds_diagrams
Weird punchline... I added another of the production roles cos we think there are messy interdependencies, and after rebooting, the result was *no* iptables firewall. That's bizarre but fine for now.
Tue, May 15
Workaround to apply every boot until this is resolved:
iptables -A INPUT -p tcp --dport 8081 -j ACCEPT
Great, we can leave this closed for now, but it began around some test deployments I did, so I'm concerned and will monitor the next few carefully.
Sun, May 13
Thu, May 10
Wed, May 9
Strange, every time I recreate the machine as a "large", which is supposed to have a 80GB disk, I only see a 20GB root partition.
We need a Gerrit admin to CR and submit this, https://gerrit.wikimedia.org/r/#/c/432145/
I'm pretty certain this won't cause 2x overall memory usage, although it is the upper bound. Some of RSS ends up being copy-on-write shared across processes, but we can't predict what proportion that will be. I think we should check memory usage on the canary box before doing the full deployment.
You know, we should probably install git-lfs everywhere we can, just like git, and do git lfs install --global as part of it.
Tue, May 8
15:50 < awight> twentyafterfour: bad news, my test LFS deployment failed to pull the files again
15:51 < awight> tin:/srv/deployment/ores/deploy/scap/log/scap-sync-2018-05-01-0003-1-gae55746.log
15:51 < awight> git lfs install --global did happen
15:51 < awight> ah.
15:52 < awight> It's probably because git lfs install happened after submodule update -i.
Slightly different results when running under ORES, it seems that performing drafttopic scoring does have a one-time effect on RES for each thread.