Adapt to ip range breaking changes in ES 5.0+#8740
Merged
Bargs merged 3 commits intoelastic:masterfrom Oct 19, 2016
Merged
Conversation
Elasticsearch 5.0 no longer returns a `key` prop with ip range buckets when from/to is used in the request. Looking at the [2.x docs][1] it appears to be a mistake that it was ever included in the first place. So now we'll generate the key ourselves. [1]: https://www.elastic.co/guide/en/elasticsearch/reference/2.4/search-aggregations-bucket-iprange-aggregation.html Fixes: elastic#8736
Contributor
|
LGTM |
The IP range agg supports open ended ranges. Elasticsearch 2.x was lenient and accepted null as a value for the from/to props, but the correct way to do an open ended range was always to omit the from/to key entirely. ES 5.0 appears to be more strict and barfs when null is passed. This commit removes the null values. Fixes elastic#8741
Contributor
|
When trying to 'click through' an open ended IP range (192.168.0.0 - *) I'm getting the following error: |
Contributor
Author
|
Hmmm, I must have missed something. Unfortunately I'm out of time tonight. I'll pick this up first thing in the morning. |
Bargs
changed the title
Contributor
|
Sent you a couple tweaks in Bargs#2 if you wouldn't mind taking a look |
Contributor
Author
|
This is the bug that keeps on giving #8751 |
Contributor
Author
|
whoops, test failure, looking |
* updated the filter labels to match the range labels * fixed the filter creation to work for unbound ranges
Contributor
Author
|
Tests fixed, ready for review |
Contributor
|
LGTM |
elastic-jasper
added a commit
that referenced
this pull request
Oct 19, 2016
--------- **Commit 1:** Generate key for ip range from/to agg Elasticsearch 5.0 no longer returns a `key` prop with ip range buckets when from/to is used in the request. Looking at the [2.x docs][1] it appears to be a mistake that it was ever included in the first place. So now we'll generate the key ourselves. [1]: https://www.elastic.co/guide/en/elasticsearch/reference/2.4/search-aggregations-bucket-iprange-aggregation.html Fixes: #8736 * Original sha: f344a4b * Authored by Matthew Bargar <mbargar@gmail.com> on 2016-10-18T22:51:56Z **Commit 2:** Stop sending null in ip range from/to props The IP range agg supports open ended ranges. Elasticsearch 2.x was lenient and accepted null as a value for the from/to props, but the correct way to do an open ended range was always to omit the from/to key entirely. ES 5.0 appears to be more strict and barfs when null is passed. This commit removes the null values. Fixes #8741 * Original sha: 3ca45ba * Authored by Matthew Bargar <mbargar@gmail.com> on 2016-10-18T23:18:14Z **Commit 3:** ip range label and filter improvements * updated the filter labels to match the range labels * fixed the filter creation to work for unbound ranges * Original sha: b153ea0 * Authored by Spencer <spalger@users.noreply.github.com> on 2016-10-19T17:57:58Z * Committed by Matthew Bargar <mbargar@gmail.com> on 2016-10-19T18:36:22Z
This was referenced Oct 19, 2016
spalger
pushed a commit
that referenced
this pull request
Oct 19, 2016
--------- **Commit 1:** Generate key for ip range from/to agg Elasticsearch 5.0 no longer returns a `key` prop with ip range buckets when from/to is used in the request. Looking at the [2.x docs][1] it appears to be a mistake that it was ever included in the first place. So now we'll generate the key ourselves. [1]: https://www.elastic.co/guide/en/elasticsearch/reference/2.4/search-aggregations-bucket-iprange-aggregation.html Fixes: #8736 * Original sha: f344a4b * Authored by Matthew Bargar <mbargar@gmail.com> on 2016-10-18T22:51:56Z **Commit 2:** Stop sending null in ip range from/to props The IP range agg supports open ended ranges. Elasticsearch 2.x was lenient and accepted null as a value for the from/to props, but the correct way to do an open ended range was always to omit the from/to key entirely. ES 5.0 appears to be more strict and barfs when null is passed. This commit removes the null values. Fixes #8741 * Original sha: 3ca45ba * Authored by Matthew Bargar <mbargar@gmail.com> on 2016-10-18T23:18:14Z **Commit 3:** ip range label and filter improvements * updated the filter labels to match the range labels * fixed the filter creation to work for unbound ranges * Original sha: b153ea0 * Authored by Spencer <spalger@users.noreply.github.com> on 2016-10-19T17:57:58Z * Committed by Matthew Bargar <mbargar@gmail.com> on 2016-10-19T18:36:22Z
airow
pushed a commit
to airow/kibana
that referenced
this pull request
Feb 16, 2017
--------- **Commit 1:** Generate key for ip range from/to agg Elasticsearch 5.0 no longer returns a `key` prop with ip range buckets when from/to is used in the request. Looking at the [2.x docs][1] it appears to be a mistake that it was ever included in the first place. So now we'll generate the key ourselves. [1]: https://www.elastic.co/guide/en/elasticsearch/reference/2.4/search-aggregations-bucket-iprange-aggregation.html Fixes: elastic#8736 * Original sha: 4ce57ac7ddde0c889741d26dbbfe30440a0fc5fb [formerly f344a4b] * Authored by Matthew Bargar <mbargar@gmail.com> on 2016-10-18T22:51:56Z **Commit 2:** Stop sending null in ip range from/to props The IP range agg supports open ended ranges. Elasticsearch 2.x was lenient and accepted null as a value for the from/to props, but the correct way to do an open ended range was always to omit the from/to key entirely. ES 5.0 appears to be more strict and barfs when null is passed. This commit removes the null values. Fixes elastic#8741 * Original sha: 70426f51c074459821730a8afcd0771f97eb9752 [formerly 3ca45ba] * Authored by Matthew Bargar <mbargar@gmail.com> on 2016-10-18T23:18:14Z **Commit 3:** ip range label and filter improvements * updated the filter labels to match the range labels * fixed the filter creation to work for unbound ranges * Original sha: f3f4fea563b229a9e655b0aa1a9803f3ee7b3091 [formerly b153ea0] * Authored by Spencer <spalger@users.noreply.github.com> on 2016-10-19T17:57:58Z * Committed by Matthew Bargar <mbargar@gmail.com> on 2016-10-19T18:36:22Z Former-commit-id: c248419
airow
pushed a commit
to airow/kibana
that referenced
this pull request
Feb 16, 2017
[backport] PR elastic#8740 to 5.x Former-commit-id: 5b22d28
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
I've included fixes for two issues in this PR because you really need both to test each one fully.
Elasticsearch 5.0 no longer returns a
keyprop with ip range bucketswhen from/to is used in the request. Looking at the 2.x docs it
appears to be a mistake that it was ever included in the first place.
So now we'll generate the key ourselves.
Fixes: #8736
The IP range agg supports open ended ranges. Elasticsearch 2.x was
lenient and accepted null as a value for the from/to props, but the
correct way to do an open ended range was always to omit the from/to
key entirely. ES 5.0 appears to be more strict and barfs when null is
passed. This commit removes the null values.
Fixes elastic#8741