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

[GIS] Updates mapping to reflect that in ES #28038

Merged
merged 1 commit into from Jan 8, 2019

Conversation

Projects
None yet
5 participants
@tylersmalley
Copy link
Member

tylersmalley commented Jan 3, 2019

On start-up, Kibana migrations check the mappings of the Kibana index to
determine if there are differing mappings, if so, we re-index the data.

When setting "tree": "quadtree", ES is actually representing it in the mapping
as "strategy": "recursive". This causes the migrations to always run. These
are both defaults for the geo_shape data type, so there shouldn't be any adverse
effect here.

It's possible this is an underlying ES issue - I would expect setting this option to be represented in the mapping when it's fetched.

cc @aaronjcaldwell

@elasticmachine

This comment has been minimized.

Copy link

elasticmachine commented Jan 3, 2019

@tylersmalley

This comment has been minimized.

Copy link
Member

tylersmalley commented Jan 4, 2019

@elastic/kibana-gis someone mind sighing off on this change?

@nreese nreese self-requested a review Jan 4, 2019

@@ -12,7 +12,7 @@
},
"bounds": {
"type": "geo_shape",
"tree": "quadtree"
"strategy": "recursive"

This comment has been minimized.

@nreese

nreese Jan 4, 2019

Contributor

You can remove strategy as well. In 6.6, geo_shape type was update to be implemented with BKD tree and all of these configuration are no longer needed. https://www.elastic.co/guide/en/elasticsearch/reference/6.x/geo-shape.html#geoshape-indexing-approach

This comment has been minimized.

@tylersmalley

@aaronjcaldwell aaronjcaldwell self-requested a review Jan 4, 2019

@thomasneirynck thomasneirynck removed the :GIS App label Jan 4, 2019

@aaronjcaldwell aaronjcaldwell removed their request for review Jan 4, 2019

[GIS] Updates mapping to reflect that in ES
On start-up, Kibana migrations check the mappings of the Kibana index to
determine if there are differing mappings, if so, we re-index the data.

When setting `"tree": "quadtree"`, ES is actually representing it in the mapping
as `"strategy": "recursive"`. This causes the migrations to always run. These
are both defaults for the geo_shape data type, so there shouldn't be any adverse
effect here.

Signed-off-by: Tyler Smalley <tyler.smalley@elastic.co>

@tylersmalley tylersmalley force-pushed the tylersmalley:gis-mapping branch from 7bf1666 to e3a51f3 Jan 7, 2019

@nreese

nreese approved these changes Jan 7, 2019

Copy link
Contributor

nreese left a comment

lgtm

@chrisdavies

This comment has been minimized.

Copy link
Contributor

chrisdavies commented Jan 7, 2019

Looks good to me, too. I just wanted to note that this appears to be a more general problem, and could resurface if someone else had a recursive strategy in one of their mappings, and then removed it. Is there a more general fix that would enable migrations to properly handle this for all cases?

@elasticmachine

This comment has been minimized.

Copy link

elasticmachine commented Jan 7, 2019

@tylersmalley

This comment has been minimized.

Copy link
Member

tylersmalley commented Jan 7, 2019

retest

@elasticmachine

This comment has been minimized.

Copy link

elasticmachine commented Jan 7, 2019

@tylersmalley

This comment has been minimized.

Copy link
Member

tylersmalley commented Jan 8, 2019

Merging this - failures are consistent with those on Master from a now reverted PR - just waiting for release-manager to build a new snapshot.

@tylersmalley tylersmalley merged commit 45dfd50 into elastic:master Jan 8, 2019

1 of 2 checks passed

kibana-ci Build finished.
Details
CLA Commit author is a member of Elasticsearch
Details

@tylersmalley tylersmalley added v5.6.7 v6.7.0 and removed v6.7.0 v5.6.7 labels Jan 8, 2019

tylersmalley added a commit to tylersmalley/kibana that referenced this pull request Jan 8, 2019

[GIS] Updates mapping to reflect that in ES (elastic#28038)
On start-up, Kibana migrations check the mappings of the Kibana index to
determine if there are differing mappings, if so, we re-index the data.

When setting `"tree": "quadtree"`, ES is actually representing it in the mapping
as `"strategy": "recursive"`. This causes the migrations to always run. These
are both defaults for the geo_shape data type, so there shouldn't be any adverse
effect here.

Signed-off-by: Tyler Smalley <tyler.smalley@elastic.co>

tylersmalley added a commit to tylersmalley/kibana that referenced this pull request Jan 8, 2019

[GIS] Updates mapping to reflect that in ES (elastic#28038)
On start-up, Kibana migrations check the mappings of the Kibana index to
determine if there are differing mappings, if so, we re-index the data.

When setting `"tree": "quadtree"`, ES is actually representing it in the mapping
as `"strategy": "recursive"`. This causes the migrations to always run. These
are both defaults for the geo_shape data type, so there shouldn't be any adverse
effect here.

Signed-off-by: Tyler Smalley <tyler.smalley@elastic.co>

tylersmalley added a commit that referenced this pull request Jan 8, 2019

[GIS] Updates mapping to reflect that in ES (#28038)
On start-up, Kibana migrations check the mappings of the Kibana index to
determine if there are differing mappings, if so, we re-index the data.

When setting `"tree": "quadtree"`, ES is actually representing it in the mapping
as `"strategy": "recursive"`. This causes the migrations to always run. These
are both defaults for the geo_shape data type, so there shouldn't be any adverse
effect here.

Signed-off-by: Tyler Smalley <tyler.smalley@elastic.co>
@tylersmalley

This comment has been minimized.

Copy link
Member

tylersmalley commented Jan 8, 2019

6.7/6.x: 54414f3

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment