Tue, Jan 21
The logic here appears to be that gc.auto is set to some value (by default: 6,700). If the number of loose objects exceeds this threshold (technically, if the number of loose objects in objects/17/ is more than 1/256th of this value), it triggers a repack (in a comment, git repack -d -l).
See PHI1613, where an install hit this warning (and resolved it by running git prune):
Wed, Jan 15
This went through cleanly.
Nov 26 2019
there is no way to bin/host query against the set of instances using a particular repository shard service
Nov 25 2019
Update Almanac definitions for all instances not on the paired db023 shard.
PHI1566 is resolved narrowly. These cleanup steps still need to happen.
(Updating addresses with bin/host query leaves the service address cache dirty (the "mutable structure cache" via PhabricatorRepository->getAlmanacServiceRefs()) so it should be followed with bin/cache purge --caches general.)
I'll flesh this out more later, but the move away from db123 = repo123 shard pairing, plus bin/host query using mysql makes it difficult to directly query instances using a particular repository service.
Minor issue that should be looked at during service sync arising from improved validation elsewhere:
I'm deploying the new host now. We just crossed a release so I'm going to manually restore it to 72f82abe07 once it comes up (see also T13359). Then, I'll resynchronize instance services for active instances.
Instance termination completed after about 20 minutes and all the volumes detached. Since the original instance can be recycled, I'm going to reattach and restart it, and throw away the replacement host.
Nov 8 2019
Oct 29 2019
I deployed the --sshd-key %k stuff to secure and it looks like that shaved ~1,000-2000ms off the total cost. The ssh-auth cost has dropped to about 200ms:
I saw things hang during deploy and the OpenSSH bug should have been fixed years ago.
I configured ControlMaster on secure.
Oct 28 2019
Sep 28 2019
Sep 23 2019
Sep 19 2019
Sep 18 2019
Sep 4 2019
Sep 2 2019
The migration in PHI1403 seems to have gone through cleanly. This workflow can continue to improve, but it's in relatively good shape now.
Everything here appears to have made it to production cleanly.
Sep 1 2019
Anecdotally from the last time around, gzipping the tarball didn't really do much. Possibly, this might more broadly imply that we'd be better off not compressing repository backups.
I believe I've moved "core/" from "instances.queryinstances" and sequenced all the followup changes properly, now, and that the only remaining piece is glue.
SyncWorkflow also depends on creatorPHID to synchronize the initial administrator account.