nice!

The move completed without errors.

Instances are moving now.

Deploying, then picking this up again.

FWIW we have seen several users attempting to distribute l33t w4r3z via Wikimedia's instance of Phabricator. I had to set file upload limits to < 8MB in order to prevent chunked file storage.

This sounds REALLY useful. Relatedly, it would be useful if I could auto-generate a task for each recurrence of an event.

I suspect some of those features have no actual use case outside very marginal nonsense like T12799, but they're "things computers should be able to do".

I want to get clear of T12798 first, but there are some other features I'd like to add to our search anyway, including:

@20after4's ears were burning

:(

(Specifically, if you update this bug should be resolved.)

I'm going to call this "resolved" since I migrated instances in T12817 successfully. There's followup work, but T12798 is probably a better point of consolidation for future work now than this task is.

Please don't forget to update Phabricator before filing bug reports.

The disabled/suspended instances finished up with no apparent issues, so I expect to move the live instances tomorrow.

A verrrry minor thing is that because we always transfer a repository backup (even if it's empty), a migration always generates a repository directory on the far end. We could maaaybe have restore remove the directory if it's empty after the restore finishes to tidy this up just a touch.

With only those fields:

{
  "data": [
    {
      "name": "Open",
      "value": "open",
      "special": "default",
      "closed": false
    },
    {
      "name": "Resolved",
      "value": "resolved",
      "special": "closed",
      "closed": true
    },
    {
      "name": "Wontfix",
      "value": "wontfix",
      "closed": true
    },
    {
      "name": "Invalid",
      "value": "invalid",
      "closed": true
    },
    {
      "name": "Duplicate",
      "value": "duplicate",
      "special": "duplicate",
      "closed": true
    },
    {
      "name": "Spite",
      "value": "spite",
      "closed": true
    }
  ]
}

Maybe just include name, value, closed and special?

Similar example for new maniphest.status.search. I'm happy to drop any of these fields if you think we won't need them (prefixes and suffixes leap to mind).

I'm moving all the disabled/suspended instances now.

With those changes, bin/instances move completed successfully.

As a sort of aside, --global --instance X is really slow right now (about 10s), and will only get slower in the future: it loads every instance page by page over Conduit, then does the remaining filtering by name locally. But it gets the right result, so this is reasonable enough for the moment. I may try to tune this before moving a lot of instances.

I hit two more minor issues:

bin/host restore failed with this error:

I read and wrote the repository and verified that the data really ended up on db012 and repo025.

I launched yellow-underneathie.phacility.com with forced services dbx012 and repox025. My goal here is to check for any code I missed which makes the assumption that dbX = repoX. I believe we don't have any of this code, but if we do, this instance should point out whatever problems we have that still need to be cleaned up.

• Swap stuff finished up.
• I merged master to stable for services/ to pick up bin/services sync --src ... --dst ....
• I merged master to stable for instances/ to pick up bin/instances move ... and related changes.
• core/ just runs master so nothing needed to merge.
• I upgraded repo025, then repo012, then admin001. None of these seemed to hit any issues.

While that's running, I closed dbx012 and repox012 to new allocations. The shard status panel correctly reflects repox025 with no paired DB service and the 012 shard as closed:

• I launched repo025.phacility.net, like other hosts in the tier.
• I added repo025.phacility.net to DNS in Route 53 (172.30.0.115).
• I added a device record (repo025.phacility.net) to Almanac on admin.phacility.com.
• I added a service record (repox025.phacility.net) to Almanac on admin.phacility.com, and bound it to the device.
• I added a device record for the backup volume, rback025.phacility.net.

I think the next steps are:

I cleaned up all that stuff and it doesn't look like I broke the world.

I think this means we don't need to migrate every host: the problem with swapping block001 over to be NAT'd was probably that the NAT gateway itself couldn't reach the public internet. When we changed the 0.0.0.0/0 rule to nat-..., that blocked the NAT gateway itself from getting out.

• I launched a new NAT gateway into the public subnet (block001); nat-0d470fc54d846a993.
• I reconfigured the private subnet route table to point at the new gateway instead of the old one.
• I can now reach the public internet from the host on the private subnet:

I think the problem is that the NAT gateway is currently in the private001 subnet, but needs to be in the public subnet (the NAT gateway itself must have a route to the public internet).

• I stopped the host, and got kicked off as expected.
• I started the host.
• Problem: This failed to magically fix anything, and I still can't connect to the public internet.

• I built a new route table, following the main route table.
• I replaced the target for the 0.0.0.0/0 rule with nat-... instead of igw-....
• Under "Endpoints", I added the new route table to the S3 endpoint so the private subnet can access S3.
  • (This wasn't immediately reflected in the "Routes" UI, but it's not important for now so I'm going to assume it's a propagation issue until I need it.)
  • (It showed up about a minute later.)
• I changed private001.phacility.net to use the new route table, with nat-... instead of igw-....
• I can still connect to the test host from the bastion.
• Problem: I still can't connect to the public internet from the test host.

• We launched a new private subnet (private001.phacility.net) yesterday.
• I launched a new instance (nat-test001.phacility.net) into this subnet, with no public IP.
• I can connect to the instance from the bastion host (bastion005), which is good.
• Problem: I can not connect to the public internet from the test host.

The behavior of arc land is complex. You can look at the source for the details, or run arc land --trace to see which commands it executes.

By headless strategy you mean the squash and merge one ?

Per @chad's link, PholioMockEditor->buildMailBody() does some improper stuff where it explicitly sets rendering targets and adds raw sections to the mail body.

Prior to October 2015, this flag only had an effect under git. This is why it says "Supports: git".

Gah I searched "mockup email" not Pholio..

Arc supports auto-deleting the remote branch as well as the local one

The version of arcanist used is the one packaged in debian.

See T12814.

I got an email about the last update but the contents look like some of the content is not HTMLized properly

A common reason for this is that users treat git push like "Save Changes", and the remote has thousands of epriestley-tmp-fix-T123-tmp-bakcup sorts of branches.

T12776#225510

999.99999.9% sure we have this tracked "somewhere"

good stuff, thanks!

I resorted to hg log -r "descendants('XYZ123')"

Maybe this was the workflow?

Oh jump to the history via pagination and scroll to it? I don't know if that's technically possible. It's interesting though.

Hmm the history view on this install is significantly different than the one on mine~

The button. That says Browse. 💃

I just came across this today, though I can't recall a time in recent history of it coming up previously. I was looking at a commit in history and wanted to browse through history at that point - if there was a way to jump to the commit history at the point from a commit, would've helped. In this scenario I knew a commit was made shortly after the one I was tracing and trying to locate - that doesn't happen often though.

Great! I was hoping this could be done with some kind of a plugin/extension. I'll look into it and let you know when I have a working solution.

To set expectations, this is an exceedingly low priority for the upstream and these tasks basically only move forward when an existing customer requests integrations.

(T12812 wants custom headers, but the only use case appears to be better covered by T12813.)