See PHI943. We should verify the modern behavior of PhabricatorGlobalLock in the presence of KILL <id> on the GET_LOCK() connection. I believe it is clear and explicit after D19702, which made the catch (...) more narrowly scoped.

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).

Well, this sucks... But thank you for taking the time to explain the situation 😃

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).

@epriestley Does this mean that phabricator isn't open to contributions?

See Planning.

@epriestley
Support for PHPUnit 5.x ended on February 2, 2018.
We need this patch for PHPUnit 6/7 ... any idea when it can be landed on master?

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.

@epriestley : our current phabricator version is c46be2a70b4db72d61e76690ef095384de2c3f91 that was landed on 04/13, will there be any issues if we directly cherry pick the recent two versions without pulling any other changes?
rP51073b972ece: Try to route cluster writes to nodes which won't need to synchronize first.Wed, Oct 17, 3:08 PM
rPbc6c8c0e93a7: Explicitly shuffle nodes before selecting one for cluster sync.

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.

One additional perspective on this:

See-Also: https://circleci.com/ideas/?idea=CCI-I-430
See-Also: https://discuss.circleci.com/t/webhook-support-removed-from-documentation-still-supported/19984

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.

https://discourse.phabricator-community.org/t/differential-ui-tooltip-flicks-on-hover/1970 has some css witchcraft to make this not happen.

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.