I'll look at the pricing breakdown and I might do some perf testing just to see if there's any real difference.

If we're using ELBs for this (which it looks like we may be able to, per above?) I don't think (?) we can do any path-based stuff.

We've been experiencing this problem from time to time as well.
In our case between two Phabricator installations.
The internal one observing a repository from a central dev server which always works fine.
Then the internal phabricator has a "mirror" URI configured for the repository to push any changes to an external phabricator installation.
This mirroring fails from time to time with the same error others have posted before (Unable to identify the reftype of 'refs/remotes/... in src/applications/diffusion/engine/DiffusionCommitHookEngine.php:404). Sometimes i could fix it by simply deleting a remote branch that was no longer needed anyway.
I've added a dirty fix now by inserting a "continue;" at line 404 so that the parser in findGitRefUpdates() simply skips unknown ref types and still imports the changes instead of failing completely with an exception.
Though i'm not sure what kind of side effects i might have introduced with this.

22280->22280 for aphlict (or we could possibly use path-based routing on the ALB instead of opening up a 2nd port?)

This is pretty sad that this bug is still open. I haven't found a way to use Phabricator with recent Mercurial, so I'm sticking on 4.0.1 ATM.

We should enumerate all the ports we're going to open up so we can do the security groups sooner rather than later. My list:

Cool, that all sounds like it's roughly what I expected. Thanks!

Skipping questions where you have the right answer:

Let's just take another look at this during/after T10448? I think that's happening soon enough and this is minor enough that it's probably not worth fixing separately.

Thanks @pooyajavan for your update. But in your solution, the Blueprint is cloning the repository, which I don't want to do that just for running a simple cmd.

Hi I have found the solution, added in stackoverflow, forgot to post it here again.

I have exactly the same problem. Any update regarding this issue?

For phabricator.wikimedia.org, we decided to go with elasticsearch, partially because we already have a massive elasticsearch cluster and a lot of institutional elasticsearch knowledge / experience. My opinion is that we made the right choice. I believe this opinion is shared by most of the folks who use our phabricator on a daily basis. I've seen zero complaints about search since we made the switch, which is a huge improvement from what I saw with mysql FTS. Conclusion: Elasticsearch seems to perform well and the results are generally better (obviously this is subjective, but like I said, no complaints from users)

My install hit this today: we're trying to upgrade from http -> https, but don't want to break users with the old http:// address in their .arcconfig (either because they haven't pulled master recently, are working on a different branch, are bisecting to a commit prior to the .arcconfig being updated, etc).

thanks. I will ask there.

The link is fixed.

Inbound mail seems to be working now.

This is very minor, but blue-underneathie is still active even though repo012 is dead, which is causing the queue to spawn impossible backup jobs that sit there retrying forever. They should fix themselves once the instance is suspended. I'll likely pursue the remaining cleanup here shortly since we haven't seen any issues in a few weeks.

Inbound mail later bounced. I think the issue is that we have a *.phacility.com MX record, but an admin.phacility.com A record. I can't recite all the wildcard vs nonwildcard DNS rules offhand, but I think the A record is shadowing the MX record, e.g. dig mx admin.phacility.com does not produce the right results. I've added an admin.phacilty.com MX record which might sort things out once it propagates.

The new paid support application is now in closed beta. This will become publicly available in the relatively near future, then become then channel for SAAS support after that. It may later become the channel for some types of free/community support (most likely bug reports, per above) but this probably won't happen for a while.

Community and us can both use the normal task form to report bugs -- the "bug report" form just had extra instructions.

OK I made a basic bug form for Discourse. Will update docs later today.

I had assumed the forms here would still be open for Community, at least bug reporting or us.

That is, the flow would be one of these:

Let's just do Discourse for now? I don't plan to get anything up on admin for at least a while.

Using @mentions in issue comments hits a policy exception because of the slightly odd way pact policy filtering works.

This works now: PHI1

Test mail from the console now gets routed/accepted properly but real mail still doesn't. I'm going to write this off as possibly being a route propagation issue for a little bit and see if it fixes itself.

Email replies don't actually work since mail gets routed to the web tier (mail.phacililty.com) which can't hit admin. I think I can fix this with a mail route.

Some stuff I'm thinking of doing in the short term:

This is entering some kind of closed beta shortly, I'll follow up in T12904 for actual feature improvements to the Support application.

Thanks @avivey for your info.

Since the History is now dumbed down and separated from the Technical details on the Graph view, it might be more useful to filter out merge commits from the History view. Perhaps they can be replaced by a small "Merged to <branch>" link at the bottom of the box for the last non-merge commit that was part of the merge.

Ah, that makes sense. Everything else sounds entirely reasonable to me on the "VPC per customer" plan.

In T12847#229598, @epriestley wrote:

bastion host per subnet

Is "subnet" a typo or am I thinking of the wrong subnets? Not 4 bastions per customer, right? Don't the bastions have to be in the customer VPCs?

bastion host per subnet

So having done a bunch more reading/thinking about private cluster isolation, I'm starting to lean towards "one VPC per customer per region" instead of "one subnet per customer per region".

I think we end up more consistent overall if "Resign" and "Accept" have the same behavior in this case.

That sounds less surprising to me, in the sense that it's not an explicit reversal of having requested changes. I can imagine arguments in both directions for the resign case.