In T8510#179818, @epriestley wrote:

D16094 should improve things, let me know if you identify specific problems after deploying that. It's deployed on this server now, although we have fewer similarly-named projects so it's harder to see the effects.

D16094 should improve things, let me know if you identify specific problems after deploying that. It's deployed on this server now, although we have fewer similarly-named projects so it's harder to see the effects.

It's expected that the ordering in "Browse" is alphabetical/raw, and I don't plan to change that.

Here's what happens when adding wikidata project tag using the comment form typeahead:

I have commented out internals of entire function that contains apc_sma_info() request and everything seems to be working fine :)

I have just tried ubuntu 16.04 LTS with php 7, apcu and apcu-bc and i can confirm that with apcu enabled there are issues with php random crashing with "zend_mm_heap corrupted" likewise T10987

So, as a conensus... for php7 installs people are just disabling apc/apcu?

This has been live for some time now.

D16045 reduced this to one query. We can cache it more aggressively and amortize the cost to 0 queries, but I'll leave that for T11096. This is no longer wildly out of line in terms of cost/value.

Here's at least one specific reproduction case which still isn't working well:

D16001 likely provides an appropriate general-purpose mechanism for the user cache pool.

Observed repositories should now version in a reasonable way.

(I marked D15981 as fixing this but I'm going to leave it open for confirmation since I'm not completely sure there weren't more cases that I missed.)

T6102 and the downstream also contain discussion of a second case which does center around exact matches -- searching for "Wikidata" -- but I can't reproduce it at HEAD:

D15981 doesn't, strictly speaking, prioritize exact matches. However, it should fix the underlying issue.

For issues with Ubuntu 16.04 LTS and acpu with PHP7 giving rise to "apc_sma_info() not found" Exceptions then you could install backward compatibility library package php-apcu-bc_1.0.3-2_amd64.deb using dpkg once downloaded from future Ubuntu Yakkety release universe repository. No doubt this deb will get back-ported to 16.04 LTS soon enough assuming phabricator itself isnt updated to no longer reference this missing function.

Two of the three issues discussed above (lock granularity, severity of device enrollment) got tackled. I think I have an attack on versioning hosted repositories, but I'm not going to try to squeeze it in before the release cut today.

I think this is the current state of the world. I'm planning to tackle the three major issues noted below (observed repository versioning, repository lock granularity, device enrollment behavior) and then try to wind down this phase, move all this followup work to a new "make clustering more powerful" sort of task, and then plan where to go from there based on which goals are most important (scalability vs multi-region vs read-only vs hg/svn vs drydock vs whatever crops up as installs actually deploy this stuff).

T10748 is wrapping up, and repositories now show cluster status in the new "Storage" panel of the new UI:

T10748, which provides the new cluster management UI for repositories, is nearing completion. This makes cluster setup more manageable and at least provides a pathway forward for Almanac stuff in the future, although it does not yet make Almanac / service management explicitly selectable when creating a repository (for now, new repositories allocate on a random open service).

I'm still not really thrilled with where the documentation situation on repositories is, but it's getting a little more manageable.

FWIW I have updated to Ubuntu 16.04 locally and haven't had any issues with Arcanist.

I'll fire up a VM this weekend and see if there are any issues.

@epriestley I misstated that. My intention was to say that Ubuntu is a platform which a decent chunk of people use. I definitely don't have data to back that up for Phabricator (And I don't think you guys have telemetry to be able to tell either).

This is also maybe a good time to fix all the bad old mysql vs mysqli stuff, mostly:

D15781 is promising and it looks like we can do this purely on the client if it has relatively old PHP, without requiring relatively new MySQL and special configuration on the server.

Mixed progress. Repository clustering has been stable in production since the last update, and appears to actually work, which is good. We've hit a few minor snags (like a missing sync-before-read in diffusion.querycommits) but all pretty much expected stuff and nothing troubling.

secure is now running repositories in fully redundant multi-master mode. This appears to be working, although it has been live for about 20 minutes and survived about three pushes so far so I'm not yet brimming with confidence about it.

@epriestley, ah! I get where you're going now, though I'm not sure why I missed it before. *Sips more coffee.* Sorry.

Yes, Ubuntu is very popular. We use Ubuntu ourselves. This very server is running Ubuntu.

I host phabricator on Debian with php7. And it works fine, except APCu caching.

Apparent temporary workaround if anyone hits this because they upgraded to Ubuntu 16.04. Not yet tested (since I'm still on 15.10 right now), but I have confirmed that the package repository in question is live and contains the proper packages.

@epriestley, oh, *THAT*. When people are running Linux servers, Ubuntu actually is one of the leading distros because of the ease of setup and use. According to w3techs, nearly 32% of all Linux servers are running Ubuntu. It's second only to Debian.

@CodeMouse92, I'm specifically curious about the claim I quoted: that Ubuntu 16.04 is a major platform for Phabricator hosts.

@epriestley, he's right, see the official Ubuntu 16.04 release notes. More info here and here.

Ubuntu 16.04 ... is a major platform for Phabricator hosts

I think it might be worth noting that Ubuntu 16.04 which releases soon (and is a major platform for Phabricator hosts) will be shipping with PHP 7 only, with a hard path to install PHP 5.

Just some cleanup today. New daemon console now shows which hosts daemons are running on:

This is now in production and appears to be working properly.

A big chunk of this is finally in production and seems to be working, which I'm thrilled about.

This is happening generally as part of T10751. I'm just going to close this out since I don't think it's useful as a separate task.

I slightly reduced the amount of header magic, and the notification stuff is now cluster-ready (in theory, at least). I'm planning to get notifications, web nodes, and databases redundant in production today, and maybe repositories/daemons if nothing else comes up. No issues with repo bookkeeping so far but even if it's smooth sailing it needs a fair bit of UI work, and same with the daemons.

I'm currently thinking about making this configuration push-based instead of pull-based: each server is told about other servers it should publish to when it starts up. When it receives a notification, it publishes to all those servers (with reasonable mechanisms in place to prevent cycles).

Given current progress and velocity, I'm aiming for a timeline roughly like this:

I've started moving these changes into production (T10784) so I can begin gathering confidence that they actually work. The repository stuff definitely still doesn't work since several core pieces are currently implemented as // TODO comments, but it has the synchronization bookkeeping in place for all the locking/versioning: if that's stable, it will give me confidence that we're on relatively firm ground and can move forward.