Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

switch projects to use elasticsearch 5.x #25

Merged
merged 2 commits into from
Oct 25, 2018
Merged

switch projects to use elasticsearch 5.x #25

merged 2 commits into from
Oct 25, 2018

Conversation

missinglink
Copy link
Member

Depends on pelias/schema#323, please merge that first and wait for a new version of the pelias/schema:latest branch to be published to dockerhub.

Many projects are also based off the experimental pelias/schema:portland-synonyms image, so that image will need to pull in master after 323 is merged and then republished to dockerhub.

container_name: pelias_elasticsearch
restart: always
environment: [ "discovery.type=single-node" ]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is it possible for us to set this as a default in the Dockerfile itself? It would be ideal to not have to specify it everywhere including in the schema documentation.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can try, actually I wanted to mention this setting to you, apparently, bash doesn't support exporting vars with a . in them (try it!) so it'll have to be done in either elasticsearch.yml or via a flag for the elasticsearch binary.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yikes, that's fun. I'm sure we can figure out a solution :)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

oh yea it's easy, I'll publish and remove the references to it

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

resolved via rebase

@Joxit
Copy link
Member

Joxit commented Oct 4, 2018

We are testing this with pelias/schema:support_both_es2_and_es5.
I have some deprecation warning in es5 while importing, but nothing serious

The [string] field is deprecated, please use [text] or [keyword] instead on...

Some other warning:

Deprecated field [type] used, replaced by [match_phrase and match_phrase_prefix query]
Deprecated field [slop] used, replaced by [match_phrase query]
Deprecated field [query] used, expected [filter] instead

@orangejulius
Copy link
Member

orangejulius commented Oct 4, 2018

Yes, those can't be fixed (yet) because they would break compatibility with ES2. But one of the great new features of ES5 (over ES2 where it exists but is hard to use) is that the deprecation log is enabled by default.

So when the time comes to upgrade to ES6 we will be well informed :)

@Joxit
Copy link
Member

Joxit commented Oct 5, 2018

Okay :)

I set up our pelias server with es5 (api.staging.pelias.jawg.io) and es2.4 (api.pelias.jawg.io) versions.
Specs are full WOF and France only for OA, OSM and Polyline

The UI is here https://pelias.jawg.io/

I will do some tests tomorrow ;-)

Copy link
Member

@Joxit Joxit left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

Results of Acceptance tests for France:
ES2.4:

Aggregate test results
Pass: 283
Improvements: 11
Fail: 107
Placeholders: 0
Regressions: 264
Took 31463ms
Test success rate 59.63%

ES5:

Aggregate test results
Pass: 285
Improvements: 11
Fail: 107
Placeholders: 0
Regressions: 262
Took 28237ms
Test success rate 59.94%

The main difference is in autocomplete for San Francisco and that's not very significant here.

Waiting for pelias/schema#323 now :)

@missinglink
Copy link
Member Author

FYI we decided not to merge all of pelias/schema#323 for now, so we pulled out the 'good bits' in to pelias/schema#328 and merged that to master

orangejulius and others added 2 commits October 25, 2018 11:10
There has been some confusion after we switched the Docker images to use
a non-root user. It's now fairly easy for permissions to be set
incorrectly.

This line in the example script should make things right.
@missinglink
Copy link
Member Author

@Joxit FYI we are going to start running all the docker projects on 5.6 now, so 🤞 there are no issues, but if anything comes up please let us know.

We're going to hold off doing our geocode.earth kubernetes upgrade for a little bit, until we're confident it's running ok in docker-compose.

@Joxit
Copy link
Member

Joxit commented Oct 25, 2018

Okay, I'll also see from our side if we will upgrade our places.jawg.io to ES5.6.

If we do, I'll inform you if we have any issues 😉

@orangejulius orangejulius deleted the es5 branch November 5, 2018 20:06
calpb pushed a commit to sorelle/docker that referenced this pull request Mar 29, 2021
switch projects to use elasticsearch 5.x
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants