- User Since
- Nov 28 2011, 9:35 AM (273 w, 4 d)
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.
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: WIP: Cluster "Search Servers" config and back-end abstraction
As currently implemented, search.servers looks like this:
Wed, Feb 22
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:
Mon, Feb 20
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.
Sun, Feb 19
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.
Sat, Feb 18
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.
Thu, Feb 9
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?
Mon, Feb 6
Fri, Feb 3
Thu, Feb 2
@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
Wed, Feb 1
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.
Tue, Jan 31
Sun, Jan 29
Sat, Jan 28
Fri, Jan 27
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?
Jan 25 2017
Jan 18 2017
Dec 5 2016
Dec 4 2016
Dec 2 2016
Dec 1 2016
Nov 23 2016
This all seems reasonable, I'm actually not 100% sure what happened so I'll try to gather a better understanding of the situation ;)
Nov 22 2016
Nov 18 2016
Nov 17 2016
Nov 15 2016
Fixed in config
Nov 14 2016
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.
Nov 10 2016
Oct 13 2016
Somehow this didn't autoclose.
Oct 12 2016
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:
Oct 9 2016
Also, reindexing is required after switching to innodb.
Does InnoDB FULLTEXT respect ft_boolean_syntax? If no: is there another similar option? If no: we need to parse queries ourselves and submit the +A +B version to the backend (see also T10642).
That's some pretty awesome support for an unsupported prototype. Kudos!
Oct 5 2016
Oct 2 2016
@vanmeeuwen couldn't you use custom forms to lock/hide the policy controls on the maniphest task submission / edit forms? That's how we handled it at Wikimedia's Phabricator. As mentioned above, Custom Forms is the general way forward for controlling default task policies.
Sep 29 2016
I doubt that upstream is interested in adding yet another configuration option, however, in case anyone runs across this issue, the following patch will make phabricator work with newer elasticsearch versions (2+)
So far innodb is working. I can't say if it's worse than myisam really, seems pretty similar. Stemming would help a lot but the main complaint I have is the ranking algorithm seems really bad. It doesn't return the most relevant results first. myisam had the same problem though.
Sep 28 2016
With InnoDB now mostly finished indexing, search seems to be working and the service isn't getting killed by locked tables. More info at the link I pasted above ^
Wikimedia is considering another stab at elasticsearch because we just hit a fairly serious scalability issue with myisam (https://phabricator.wikimedia.org/T146673) and it looks like innodb isn't a lot better. In addition to that, the mysql fulltext engines don't seem to handle stemming or even simple prefix matching.
+1 for mentions, that would serve the same purpose as see also: or related tasks: would. Primarily it would just be nice to be able to see them in one place instead of hiding in comments...
Sep 24 2016
Sep 21 2016
We use a text field for a 'reference number' which refers to tasks imported from bugzilla reference=bz123, or RT with reference=rt456
Sep 19 2016
Here are 2 use-cases which are both essentially the same in all the important ways:
Sep 18 2016
@epriestley: Are you open to patches that add more information to the calendar.event.search response? It currently does not even include the event time which is a pretty crucial detail to make the results useful.
Sep 14 2016
Sep 10 2016
Sep 9 2016
Sep 7 2016
IMO, Pokémon catching is an essential feature, please implement that first.
T10612: Editing a panel causes it to duplicate in dashboard may be the same root cause as this bug.