Can we avoid filling the output buffer in subprocesses by testing if writes to stdout would block? (This should also be a "yes".)

See T12996 for spiritual followup.

This is now in stable, and deployed here and to the Phacility production cluster.

For record-keeping, this was asked again in https://discourse.phabricator-community.org/t/469

We had to write some code to make phage work with exec and fix the phd stop flow to use --force, but this deploy completed successfully.

Modern flow is:

Some followup SHOW INDEXES from the case in PHI47 provided output which didn't have any evidence of key cardinality issues, so it seems less likely that this is a cardinality problem.

In T9548#229910, @indygreg wrote:

https://www.mercurial-scm.org/repo/hg/file/default/contrib/phabricator.py is a Mercurial extension that allows you to send a series of changesets to Phabricator by calling Conduit APIs directly. The extension is currently tailored for the use cases of the Mercurial project itself, isn't distributed with Mercurial, and may require Mercurial 4.3. And it obviously bypasses Phabricator's built-in Mercurial server. But if you are willing to live with the caveats, you may find it a suitable workaround.

An unusual case here is Herald rules which take the "Send me an email" action, and act "only the first time". Their current behavior will be to activate when the draft is created, have their mail killed later in the pipeline when the Editor declines to generate any, and then never fire again.

I deployed this to secure without issue, so it looks like LOCK TABLES ... is promising as a general tool for migrations.

We actually already have bin/remote stop, I just run it so rarely that I forgot about it.

Next chapter: T12989: Phacility Deployment: 2017 Week 38

vault002 is dead. Long live lb001.

This is now deployed on this server, we'll see how it holds up. It won't promote to stable until next week, and I'd discourage anyone from picking it up right away.

This has promoted to stable. See T12974 for upgrade guidance. See T12985 for one followup change. This may still have some bugs (or it may scale very differently on real-world workloads and need substantial additional work) but I think we can handle those separately.

Swap DNS.

• I opened up 22 -> 2223 on lb001.
• I allowed external 22 in the security group.
• I hard-coded my hostfile and cloned successfully:

I'm going to take a stab at this now since I think it's non-disruptive and straightforward.

We use Almanac + Passphrase + Ansible + (Dynamic inventory client) for this.

It's also possible to write a custom instances.do-exactly-what-we-need sort of endpoint and generalize later if that seems like a more promising approach.

The other shadow lurking in the water here -- which I think we can mostly avoid -- is that Almanac is mostly a-bit-bare-bones-but-overall-pretty-functional, except that the way properties on Bindings and Services are specified and edited is complete garbage. You more or less just have to magically know which properties are valid, and there's no real support for defaults or nice UI controls or hints about what you can set or suggestions that you're making stuff up and probably typo'd something.

The "most right" way in terms of consistency is to fully convert Binding to EditEngine, then implement almanac.binding.edit which can create/edit bindings. When creating a binding, it would require transactions specifying the service and interface. PhamePostBlogTransaction is sort of an example of this: when you create a new post with phame.post.edit, you must specify a blog transaction.

What's the best way to add API endpoints for resources like bindings? Call it almanac.create_binding and have it take a service and an interface as arguments?

Yeah, this is hard coded here:

In Mercurial, can a branch have some open heads and some closed heads?

(Mentioned in https://discourse.phabricator-community.org/t/run-herald-rule-for-each-push/299)

This seems like a legacy data issue that's probably unique to this install. The only way I could reproduce it locally was: