@ksmith: Thanks to the new 'favorites' menu, each user can customize their menu, there is no longer a global 'create new' menu, as it's been replaced.

In T12314#213245, @epriestley wrote:

Weakness: Subtyping is Probably Only Useful in Maniphest

Subtyping is likely to involve a large number of changes in shared infrastructure (EditEngine), but they will probably only ever be useful in Maniphest. Although most applications now use EditEngine, I can't really come up with any good use cases for subtyping in other applications. Perhaps Calendar could use subtyping on events, but this feels like a solution searching for a problem.

I don't suppose users count as objects in this context? I'd love to have a way to be notified of new @mentions for my username. A client app that queries conduit occasionally and sends me desktop notifications, well, that would just be super cool.

I agree that results should almost always be on the first page and ideally near the top of the first page. I'm also tempted to say that 10 results per page might be closer to the right number than 100.

I'll investigate further into the slowness (I wasn't involved in the debugging so far so I don't know more than what's said in the task)

In D17384#208882, @epriestley wrote:

• Using the same objects as both Host and Service feels confusing to me. I think this would probably be clearer as separate Service and Host classes? Like PhabricatorMySQLSearchClusterService extends PhabricatorSearchClusterService and PhabricatorMySQLSearchClusterHost extends PhabricatorSearchClusterHost or similar. Particularly because setHostRefs() seems like it's getting called with a raw dictionary in one case and a list of objects in another? And then there's weird magic around getHostRefs() for the MySQL case?

I'll split out the changes to the engine if I can figure out how to do that... Update coming soon.

@epriestley: Ok I believe this addresses all of your feedback and other than documentation it should be very close to finished.

Address epriestley's feedback about tooltip and string concatenation

• Fixed up the cli workflows for search init and search index
• Misc other cleanup

Fix elasticsearch setup checks

Simplified PhabricatorElasticSearchQueryBuilder, no more __call magic

Eliminate fancy expressions in string

• Addressed outstanding review feedback
• Drastically improved elasticsearch query construction

This actually seems a little difficult to fix...maybe just make it truncate with an ellipsis?

heh nice. And I didn't even have to cheat by using U+00A0.

For wikimedia's "scap" tool we built a feature called "checks" which are configurable commands that run on each target machine and confirm if the desired commands were successful.

This is something I've wished for a few times. Along with just searching for repositories in general.

Implemented @epriestley's suggestions and cleaned up the code quite a bit.

The commit cache should be a fairly large performance win.

Great feedback, thanks! I'll update again over the weekend or early next week.

My impression is that there is a lot of room for optimization in the RepositoryPullLocalDaemon. I've wanted to tackle that for a while because it causes a fair delay between when a commit goes into git and when it actually shows up in Diffusion.

doh. I arc diff'd from the wrong git state. This is better, I hope.

In D17384#207765, @epriestley wrote:

Can you just have the "mysql" service not accept any hosts in its configuration (i.e., always use the same Phabricator hosts)?

This implements 'service' level config with individual hosts that can have
one or more 'roles' assigned. Currently roles are 'read' and 'write'

ugh, this was supposed to update D17384: Support multiple fulltext search clusters with 'cluster.search' config

As currently implemented, search.servers looks like this:

FWIW I think this is pretty genius. Especially the repro-or-it-didn't-happen aspect.

There is a small issue with what I've been doing here, so far:

Awesome, thanks for the guidance! All very good suggestions, I think it makes sense to have a ThingYouCanHealthCheckInterface and I agree that services make more sense than servers. The scenarios you mention are exactly the kinds of functionality I'd like to make possible.

I totally get the motivation to have a strong collection of highly integrated tools which all work together seamlessly and provide a value that is larger than the sum of it's parts.

In D17300#206257, @epriestley wrote:

Looks good. Couple of minor nits inline.

Your test plan should also include something like this:

• Edited a repository to have "platypus" in the description, searched for "platypus", found the repository.

Even when bin/search index works, the actual "edit stuff with the web UI" workflow may still not be fully hooked up. Usually, this is because the Editor does not override supportsSearch(), so edits don't rebuild the index. In this case it looks like you're in the clear, so I'd expect this to work correctly with no further changes, but it's worth double checking.

Cool stuff. I didn't see you already had made so much progress before I commented on T12218. You can safely disregard my clustershell suggestion.

@epriestley: Have you seen clustershell? It's a massively scaleable management shell with some pretty interesting features. Wikimedia operations are adopting it in place of a lot of dsh and saltstack stuff. From what I have seen it is a really solid framework to build upon.

Interestingly, phabricator_maniphest maniphest_transaction gives zero results but "phabricator_maniphest" "maniphest_transaction" works. Seems like the underscores are a problem as much as the period.

Maybe phabricator should automatically try adding quotes to a search if the initial query returns zero results?

@epriestley: This all sounds excellent. I'll start by fixing any instances of

I have this working downstream in Wikimedia's instance of phabricator, however, our fork is significantly modified. I intend to refactor this into something that is either a) mergeable upstream or b) installable as an extension but for now the code is on phabricator.wikimedia.org PhabricatorElasticFulltextStorageEngine.php

So, @epriestley: How do you feel about me taking over elasticsearch backend and moving it out to an extension rather than keeping it in phabricator core? The other possibility is I could just fork the elastic backend and name it something different, as it seems phabricator already supports loading the engine extension dynamically.

@ramm: I'm already on it: https://phabricator.wikimedia.org/T155299

In T9530#177353, @hach-que wrote:

So I was thinking about software components recently and one of the issues I've had with both Jenkins and Harbormaster is that builds of one repository aren't aware of the builds from another repository. This is a common scenario in the software I build:

In D17259#205427, @chad wrote:

Truth be told I have a diff locally that removes serious business more for all boring all the time.

Our DBAs are currently in the process of testing the a patched mariadb package. I will try to keep you posted on that progress but it looks like the fix is now backported to 10.0

Is there any way that getCustomPHID would return false/null when it's a non-admin editing favorites?

In T5000#176440, @epriestley wrote:

Another possibility is that we just build this behavior (intercept and react to ref changes) as an extension point prior to the Herald, and then you can implement whatever magic you want. I suspect very few installs want the default behavior of git push origin mybranch for arbitrarily named branches to be anything except "create a branch".

This all seems reasonable, I'm actually not 100% sure what happened so I'll try to gather a better understanding of the situation ;)

hahahah nice.

Fixed in config

FWIW: I believe @paladox means well, he's just young/inexperienced and overly enthusiastic. The decision to ban him is entirely reasonable for upstream though, given the circumstances.

In T11034#199653, @epriestley wrote:

---

Now that this has been deployed for a while, I'm curious if there's any feedback about it? Specifically:

• Does this approach generally seem like it's a reasonable solution to the problem (if not in its current form, in some similar form which handles these issues more gracefully)? Or are we not really in the right ballpark?

Somehow this didn't autoclose.

Would it be safe for me to write a migration that sets utcInstanceEpoch equal to utcInitialEpoch on every row in the calendar_event table?

After running the migrations, some instances of recurring events end up with null for the utcInstanceEpoch column. I'm not sure how this happened, however, as some of the instances have a value that matches utcInitialEpoch and I'm not entirely sure what the purpose of utcInstanceEpoch would be. If it matches InitialEpoch then it seems kinda useless, as does null...

@epriestley: Sounds good to me, this seems quite sensible in every way.

@epriestley: Jaime, Senior DBA at the WMF, has posted some answers for your list of questions:

Also, reindexing is required after switching to innodb.