Thu, Aug 2
Wed, Aug 1
Tue, Jul 31
this will happen in cirrus, not as an elasticsearch plugin
As pointed out by Manybubbles this will be completely fixed once we fully get rid of elasticsearch query_string. This work is being tracked in T185108.
moving to waiting/blocked waiting for the hebrew plugin
If this submodule is not referenced by anything else other than mediawiki then there should be no reason to bump it in deployment-prep, I'd be for resetting it to 4db9d40d28d61c53cdbca77059d9a2a6e714af89 to match prod.
Side note: I'm pretty sure that https://gerrit.wikimedia.org/r/c/operations/mediawiki-config/+/300880 was unnecessary. This submodule in mw-config is not meant to be updated whenever a change to it is applied, only when schema used by MW is updated.
Then to the question: why event-schema was bumped directly on deployment-tin? I have no clue, so if nobody requires it I'd be for cleaning it and align it to prod.
this works as expected now.
Pinging @Pchelolo as he may use this repo for testing purposes.
Mon, Jul 30
Found a possible reason for this to happen and filed a bug upstream: https://github.com/elastic/elasticsearch/issues/32467
In short the completion suggester code does handle gracefully shard failures during the fetch phase causing the response received by cirrus to not contain the necessary information.
will try to look at this again
Thu, Jul 26
Mon, Jul 23
Thu, Jul 19
by forking the elasticsearch and use github zip export I could find a way to make it work, now cirrus tests are failing.
This should at least allow us to move forward.
Preliminary package (without hebrew) available at : https://people.wikimedia.org/~dcausse/wmf-elasticsearch-search-plugins_6.3.1-alpha1~jessie_all.deb
Jul 18 2018
I'm stuck on this because we still have to support HHVM but unfortunately we can't activate hhvm.php7.scalar_types (see T173786#3688184). The new elasticsearch php client has many statements such as declare(strict_types = 1); which triggers this fatal error:
Fatal error: strict_types can only be used when hhvm.php7.scalar_types = true
Happened today again on elastic1030,
Jul 17 2018
Jul 16 2018
Jul 13 2018
clean_api_prefix_redirect_accent_squashing_accented_namespace_suggest_search_prefers_main_namespace_over_crossns_redirects seems due to a instability in the scoring function:
clean_api_update_deleted_redirects_are_removed_from_the_index can be explained because of https://gerrit.wikimedia.org/r/c/mediawiki/core/+/445581
Jul 12 2018
@Johan thanks for the feedback!
Yes the goal is really not to remove the prefix keyword, expert users will still be able to use it at will.
I'll move forward and implement your suggestions on the phrasing and wait till the end of next week for possible feedback from the Tech News.
Jul 11 2018
Without the full stacktrace I'm not entirely sure that the attached patch will fix the issue but I've seen similar behavior while upgrading to 6.3.
I suggest to wait and see if the error disappears after we migrate to 6.3.
Jul 10 2018
Jul 6 2018
Jul 5 2018
just to add a note that I discovered this morning that elastic will refuse to boot if the other cluster you setup like:
search: remote: other: seeds: 10.11.12.1:9300