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.

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.

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.

Thank you for the answer, appreciate it, and your effort that goes into arcanist.

The non-public parts of Phage are currently very specific to Phacility's cluster and probably not generally useful. The current version of PhageRemoteWorkflow is similar to P2107 and depends on particular Phacility services and hosts to enumerate valid remotes and negotiate a connection to them through a bastion pool. These service-listing and bastion-host components are not generalized and not trivially generalizable.

It seem to me like certain parts of phage are not published in a public repo. Are there plans to open up missing pieces?

4. As Alice, commandeer a revision authored by Baliey and reviewed by Claire. Edit it locally to do arbitrary bad things, then git push it.
5. Make a commit, edit the commit message to say Differential Revision: D1234, where D1234 is a current, valid, accepted revision authored by anyone, then git push it.

I believe it is extremely difficult to configure Phabricator to provide the assurance you describe, particularly if arc land does anything. If you are actually providing this guarantee ("an attacker needs two machines"), you can likely add a clause to the large amount of custom code you've written to prevent self-foisting while still supporting other foisting use cases. If you haven't written a large amount of custom code, I suspect an attacker can fairly easily deploy with one machine without using "Foist Upon".

Is there a way to disable this feature? Our security team has noticed that with this feature we can land code with just a single person's machine being compromised (we rely on an attacker needing two machines to deploy code as a safety mechanism). I.e. You make a revision, Foist it on someone, Approve it, then arc land it as the other person (saying y to the prompt).

See also T12404#256288 for a note on each removal.

each is usually easy to replace and I'm happy to accept a change to replace it if someone wants to reproduce/test it. I believe this (totally ridiculous) construction:

From https://discourse.phabricator-community.org/t/sending-emails-causes-an-exception/4966, looks like the PHPMailer uses each which is removed in php 8.

From https://discourse.phabricator-community.org/t/sending-emails-causes-an-exception/4966, it appears that both class.smtp.php and class.phpmailer-lite.php have calls to each which is removed in PHP 8.

So that part is correct, but swapping the commit and branch was incidental, and I overlooked it because we usually get the same result: in common cases, this is moot because ancestors(<branch name>) is equivalent to ancestors(<heads of that branch>), and branch(<commit hash>) is equivalent to branch(<branch of that commit>). The latter is always equivalent; the former is equivalent when commit is the single head of branch, which it almost always is in regular use.

But this behavior (on this install) is unambiguously wrong:

...since b7be5c961297 (the parameter) is an ancestor of 162a9c1e8e44 (the first commit in the result set). I'll send you a diff.

Good catch!

One tangential thing I noticed from the error messages in these cases, in DiffusionHistoryQueryConduitAPIMethod the getMercurialResult() function executes this hg command

$path_args = array();
if (strlen($path)) {
  $path_args[] = $path;
  $revset_arg = hgsprintf(
    'reverse(ancestors(%s))',
    $commit_hash);
} else {
  $revset_arg = hgsprintf(
    'reverse(ancestors(%s)) and branch(%s)',
    $drequest->getBranch(),
    $commit_hash);
}

With just the updates to the future handling this is now the landing page I see with missing commits:

Ah, that's helpful. I found a repro, it's specific to the behavior of the ImmediateFuture pathway for non-clustered resolution of Conduit "calls". This should force it from any configuration/state, I think:

I'm able to reproduce this but I'll investigate further

I think I did conflate this partially - namely that this isn't directly caused by the issue discussed in T13365. Where this issue came up for me is while testing out D21715, I removed the head commit from the on-disk repo which caused the landing page to not render properly:

I'll have some more detail in D21717 in a minute, but I can't immediately reproduce this, I think? If I intentionally break diffusion.historyquery like this:

In Mercurial, I'm not exactly sure how wide this window is. Since you normally can't strip commits in the remote by pushing (AFAIK?)

This is true, though it does change a bit if we enable evolve server-side. Then when commits/branches are pruned when pushing/pulling those obsolete markers will also be transferred, allowing similar disappearing commits (retrievable via —hidden). However I believe by default mercurial does not allow pruning public changesets (would require forcibly changing phases on client/server, or running a server/branch in non-publishing mode). Supporting evolve/topics server-side is probably large enough that it would be its own big project. So I think this assumption holds up well.

(D21715 is still a draft, but I left a couple of more specific comments there.)

Does this refer to when multiple dependent commits are pushed and then stripped from the on-disk state?

Another caveat here is that if you destroy commits directly in Phabricator's working copy in certain states, it's possible it won't be able to trace ancestry to find all the commits you destroyed in order to mark them unreachable. However, this window is narrow. For Git, you can bin/repository mark-reachable to rebuild reachability if you know you've done a bunch of dangerous mutations to the on-disk state.

I think this is probably the cleanest fix, but I only tested event imports (which now appear to work). If you want to test Maniphest with subtypes configured (to make sure it doesn't break) and send me a revision with this change, I'll review it. Otherwise, I'll do that testing when I get a chance and land this if nothing crops up.

I found this channel incredibly helpful for repairing/replacing components on boards:

I caught one cosmetic issue in D21711, but this works properly for me locally now. Thanks!

I ran into this while trying to reproduce the issue:

The stalled transactions on this host published after I deployed the update.