Phabricator does not support per-project fields, and we have no plans to add them at this time.

Per T8744 and elsewhere, the "Synthetic Inlines" for lint and Differential coverage both still need to be switched to read from Harbormaster sources.

Thanks! This is now deployed.

niice

Aha! I think I figured it out.

SELECT * FROM phabricator_almanac.almanac_service;

Show me the row?

My theory here is that your services table is kinda messed up, but I'm having a hard time coming up with a clean way to fix this in the general case. I think I'm just going to soften the failure here for now, unless that query produces surprises.

From T8781, monitoring instance daemon queue lengths would be particularly helpful in identifying at least 1-2 issues we've hit.

Do you have stuff in almanac_service?

You can also probably do this to get a meaningful stack trace, near line 410 of PhabricatorCursorPagedPolicyAwareQuery.php:

Actually, I guess we can't check the environment that early to see if the setting is set. Let me just start by tailoring the error message, and maybe that'll give me enough to go on that I can figure it out.

Ah, okay. Let me fix that UI to respect developer mode so we can get a stack trace.

Oh, sorry, I just mean the web UI itself -- I'd expect it to look like this if you have developer-mode enabled:

Do you have a full stack trace? You might need to bin/config set phabricator.developer-mode 1 to get one, although presumably you're already in developer mode...

This looks like it was primarily caused by operator error. I stopped some services on the paired repo host in order to recover db001 in connection with T8764 yesterday. This worked, and let me revive the host immediately rather than needing to restart it, but I then failed to completely restart services later.

I think the immediate issue is now resolved, I'll look at this in more detail and post a followup a little later.

Looking into this now.

Seems resolved in the example. This is not 100% completely perfect yet (there's still some cruft kicking around) but I think it has no user-facing impact anymore.

Oh, @chad is correct, I get this mail on this install.

Thanks.

No. If there was, it would be posted here.

Thanks.

However this is, as you already mentioned, rather useless, because clicking the link will not allow to send an email

Hmm, nevermind me.

I can't reproduce this:

No worries, sorry these aren't working right now. We swapped hosts out and some of the domain rules changed a bit.

Oh, and remove the scripts from version control if their chosen destination is not Diffusion, I suppose.

Since this migration is ~18 months old and there's no easy way to correct it, I'm just going to no-op it. You'll need to update your repositories to set the correct credentials after upgrading.

We should fix this since it's confusing, but I don't want to put www.phabricator.com back in service as a host since this was the only thing it was used for.

I pushed a change to record instance out-of-service dates (D13561) and stop running backups for out-of-service instances after about 48 hours (D13563). I promoted these changes to rSAAS stable and deployed admin. I manually updated all "Suspended" and "Disabled" instances to have an out-of-service date of July 1, 2015.

(I think this is fixed?)

I stopped storage upgrade from running on out-of-service instances (rCOREe9f998b109c1) and upgraded db002 and repo002 to verify this change. We don't need to keep out-of-service schemata up to date, and this reduces the ongoing cost of out-of-service instances.

ab7dc13c67fd (Sun, Jul 5, 12:28 PM) is after the earlier patch 92b73fed6b2c (Fri, Jul 3, 10:59 AM). This is still an error with the migration.

I no-op'd the debian-start script and deployed db002 with the new changes (rCORE51d7570f5ddf) to verify it. I'm not going to restart db001 for the moment, since bringing it down is more disruptive and I only need confidence that the change is correct.

I've restarted the tier with a ~50% buffer pool configuration (4GB of 7.5GB) and 8GB swap (rCORE471d3a7acee1) and things seem to be holding stable. I'll pursue the other changes now.

Ubuntu also ships with some debian-sys-maint junk which runs huge, slow queries to check for problematic table data on every restart, which we should likely disable.

While I was writing this up, the host ran out of RAM and stopped working, so this is probably a memory management issue.

Some immediate observations:

Since your code is mostly PHP, you could possibly just run Diviner on things to get something for Google to hit. That might be way off (and we may not be able to parse/atomize things in the MW codebase correctly), but I could see it being at least as good as indexing the source itself. If someone searches for a class or function name, I think getting the definition is almost always way more useful than getting callsites -- maybe even if the hit is shell docs with a link to the definition. And in some future world where everyone has infinite time to generate wonderful stable docs, the doc hit seems clearly preferable.

...so I could get a better idea of how these fields are used. In this case, sadly. I didn't find much at all, though it probably isn't because of the robots.txt exclusion in diffusion.

https://secure.phabricator.com/book/phabflavor/article/please_please_please/

Generally, we prefer UI consistency and a simpler UI ruleset over preventing users from doing silly things.

The assumption is that you won't mix history.immutable (which compels arc not to mutate history) with rebasing (which mutates history): if you mutate history, we assume you're comfortable letting arc mutate history too. If you configure it as you have, you're locking us out of both commit messages (which we're forbidden from mutating) and commit/tree hashes (which may change after rebasing), so we don't have much to go on.

Mmmm, do you mean if I put "Differential Revision: DXXX" as the last line of the first commit of the branch, it'll be seen by arc and any subsequent arc diff will update the right review instead of creating a new one ?

Can you paste the exact error message you received?

Use arc which to understand what arc diff will do and why.

(The more-correct remedy is likely for the administrator to disable policy.allow-public or set the visibility of at least one space to "Public (No Login Required)" so logged-out users can see some objects.)

I just visited a site I don't have access to, so it should just say login or sign up.

Do you have one Space, which is available to "All Users" instead of "Public"?

This is now merged to master.

You can not delete tasks.

Also note that 20140218.passwords.2.prefix.sql is not idempotent, so re-running it if it already ran could break things.

The expectation is that 20140722.renameauth.php renamed provider classes, and 20140218.passwords.2.prefix.sql reformatted the passwords.

Can you give me an example of the kind of integration you're interested in? For example, what's a good query I can plug into Google or Bing and get a reasonable result in a codebase for?

See "Managing Storage Adjustments" in the documentation, which discusses this under "Troubleshooting":