My theory on the Drydock behavior is that we're getting into an "A, A, A" state. A lease comes in that needs a "B", so it releases a resource.

Next, I hit T13179 again. Yeesh. I rebased on my local hack-around for now.

From previous work, I already have functional Host and Working Copy blueprints locally so I'm likely punting on the Hoax/EC2 issue.

I'm happy to make these changes myself, or you mentioned wanting to contribute a patch?

I'm hoping to do a relatively small iteration here. The primary goal is to investigate PHI570, which reports some sketchy behavior. I generally want to unblock adopters of Drydock and fix critical weirdness but avoid improving it too much (i.e., avoid a real iteration on T13073) until we can clear other stuff out of the queue.

See PHI942 (internal) and PHI892 (internal).

It's "open" in the sense of Apache-licensed and (mostly) developed in public (e.g., the information on this install is public rather than hidden behind a corporate veil).

See Planning.

Plus: db018.phacility.net, repo001.phacility.net, db024.phacility.net.

One more of these just came in for repo003.

I never remember the name of this ticket, so here are the things I think it's called: phone home mothership

This currently appears to be mooted by T13188.

I think you can cherry-pick those changes safely. I suspect further changes connected to T13211 and/or T10884 in the near future are likely to be difficult to cherry-pick, though, so ideally you should try to upgrade.

To pull the list down (this takes a while since we can only grab 100 results at a time and the API takes a while to respond):

See PHI926, where a GSuite-backed install has seen multiple "550 No Such User" bounces to the same address even though the address exists. It's currently unclear if this is an issue in Mailgun, GSuite, the series of tubes between the two, or elsewhere.

One idea here: T12961 and T13012 are security issues related to the misuse of -- in argument lists. I think there was one more (less severe issue?) with Git elsewhere, too.

This is entirely reasonable, the only reason it doesn't already exist is that the lease owner may be any of several different types of objects (I think: user, repository, another Drydock object, maybe null?) and we don't have a convenient UI datasource for letting users type to select any one of these various object types.

¯\_(ツ)_/¯

I think that workflow is pretty strongly undesirable: it suggests users make an incorrect change (e.g., suggest a patch which violates the style guideline) and they're expected to answer "Y" to it.

I think this is all done but want to let things run against bastion007 for a bit before I tear down bastion005.

I also needed to copy the old master.key from bastion005 to bastion007 in /core/lib/keystore/.

I turned bastion.phacility.net and bastion-external.phacillity.net into CNAME records and pointed them at the new bastions.

There's a minor deadlock on bastion deployment with the current scripts: during deploy, we run deploy-key to copy the deploy key from the bastion to the target host during deployment, so that we don't need to put the entire keystore on normal cluster nodes, and so that we don't need to have the keystore on the control host (staff laptop) outside the cluster.

I cycled all the hosts except bastion. saux001 needs to be vetted a bit (it handles "Land Revision" from the web UI) but it isn't critical if it needs a bit more work.

I 'm going to get these underway once the deploy finishes.

For now, I just hard-wiped the cache and regenerated the documentation again. ¯\_(ツ)_/¯

The file cache says that these files have already been parsed and contain no atoms, so the rest of the program behavior is expected after that. I'm not sure how this state came to exist.

• DivinerPublisher->publishAtoms() is being passed nothing, so it's correctly deleting everything.
• The graph cache is empty.
• The actual atom.cache file on disk is empty.
• The input to the cache is empty.
• The files aren't being passed to the atomizer rules (although the rules appear to be applying correctly).

So, so far it looks like the database is in a "good" state but the publish workflow incorrectly deleted all the articles. From previous efforts, I believe dropping the cache fixes this issue.

But note that the graphHash and nodeHash columns are 0, which I believe is a signal that these nodes have been deleted (I haven't touched this code in a while).

Oh, the contrib stuff got separated into a different book and has fully unpublished:

The "Contributor Introduction" document, specifically, seems to have unpublished. Let me see what I can dig up about the current database state.

"Yes", but post- T13098.

@epriestley, would you be open to making the chunk size configurable? Changing the chunk size from 32 to 512 reduced the amount of time required for us to lint ~1500 TypeScript files from 370 seconds to 66 seconds.