• Fix a strlen() in query construction.

• Add annotations for interfaces implemented by PhabricatorHandleList.

PHP 8.1 changed semantics of static variables in methods. See:

See also T13588. Using static::class to work around changes to the scope of static in PHP 8.1 is also possible now that PHP 5.5 is the minimum version, and some uses of get_class($this) might be replaceable. There's no strong motivator for this, it's just a little cleaner.

See also T13588.

It would still be nice to have this from a completeness/correctness perspective, but other changes have made it less valuable:

...possibly, but not conclusively, a result of an SSH version upgrade...

I put all the database migration stuff everywhere and it appears stable. I'm hooking up Postmark as an outbound pathway now. If I get that working, I'll let it sit for a while and start migrating databases.

Finally, there are other some MySQL version issues which can be avoided with:

• Also fix service profiler test case.

• Fix unit tests and a handful of other errors.

The new core/ support for the API is partially deployed; the new services/ support isn't anywhere yet.

Ah, yep, should be 7.2 -- thanks!

See also T13232. Here's a possible build strategy for PHP 8.1 under macOS Mojave. Anyone reasonable should probably give up and use brew instead.

The latest version of Phabricator itself is everywhere.

I'm going to hold it until the weekend and try deploying then if things look calm on my end.

I'm satisfied that we aren't violating our commitment to our customers by continuing to use Mailgun as a service provider...

Purely venting, but the advanced version of "click here to schedule a mysterious meeting" is to outright lie -- pretending that you deeply respect the recipient's achievements -- before asking them to schedule a mysterious meeting.

While waiting to deploy db stuff, I was planning to look at pruning dead data out of S3 -- but, on closer examination, the total S3 bill is something like $1/day, so no priority on that whatsoever.

Piledriver also needs to be able to provision database hosts, but these are more-or-less a trivial subset of repository hosts.

• Make InstancesStateQuery use a dictionary when building the database ref information internally.

Piledriver also needs to be able to provision database hosts, but these are more-or-less a trivial subset of repository hosts.

I completed all the repository migrations over the weekend and seemingly haven't run into any issues.

This appears resolved: the workflow now tests that /proc/meminfo reports an appropriate value for TotalSwap.

This overlaps somewhat with PhutilSystem::getSystemMemoryInformation(), but that mechanism is narrower and also doesn't really work in practice, so it would probably be reasonable to remove it entirely.

Satisfy lint by catching and re-throwing Throwable.

Just for completeness, vault used to be an HAProxy host serving as an SSH load balancer, but this responsibility moved to lb001 once ELBs became able to listen on inbound port 22 and TCP forward, so there is no longer a vault class of machines.

The new provisioning process for repository shards is:

Piledriver was built before the FutureGraph stuff settled in T11968; it runs into the same general set of sequencing problems and yield would likely be a good approach.

See also D19941, which removed a dependency that did previously exist.

I can't figure out how to delete...

I got rid of everything I could, and nothing appears to be affected.

We have a lot of leftover VPC cruft that I'm going to nuke, notably meta and admin VPCs that (as far as I can tell) have nothing in them, and then a bunch of subnets (meta.private-a, meta.private-b, block-public-222, admin.public-a, admin.public-b, meta.public-a, meta.public-b, block-private-3) and some NGWs etc. I'm like 99% sure this stuff is all leftover from testing years ago and nothing depends on it, but I guess we'll see what happens when I delete all of it.

Here's the last known state of the world from T12816:

See also NAT carryover from T12816, via T13542.

Closing this in favor of T13630, which covers the same ground.

I'm planning to simply delete the Discourse forum without preserving any content.