PPL command expression implementation for geoip
#3228
+997
−106
Conversation
This file contains 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
andy-k-improving
force-pushed
the
ft-ak-iplocation-cmd
branch
from
6138a91 to
16a8f8f
Compare
7 tasks
Signed-off-by: Andy Kwok <[email protected]>
Signed-off-by: Andy Kwok <[email protected]>
Signed-off-by: Andy Kwok <[email protected]>
Signed-off-by: Andy Kwok <[email protected]>
Signed-off-by: Andy Kwok <[email protected]>
Signed-off-by: Andy Kwok <[email protected]>
Signed-off-by: Andy Kwok <[email protected]>
Signed-off-by: Andy Kwok <[email protected]>
Signed-off-by: Andy Kwok <[email protected]>
Signed-off-by: Andy Kwok <[email protected]>
Signed-off-by: Andy Kwok <[email protected]>
Signed-off-by: Andy Kwok <[email protected]>
Signed-off-by: Andy Kwok <[email protected]>
Signed-off-by: Andy Kwok <[email protected]>
Signed-off-by: Andy Kwok <[email protected]>
Signed-off-by: Andy Kwok <[email protected]>
Signed-off-by: Andy Kwok <[email protected]>
Signed-off-by: Andy Kwok <[email protected]>
Signed-off-by: Andy Kwok <[email protected]>
Signed-off-by: Andy Kwok <[email protected]>
Signed-off-by: Andy Kwok <[email protected]>
Signed-off-by: Andy Kwok <[email protected]>
Signed-off-by: Andy Kwok <[email protected]>
Signed-off-by: Andy Kwok <[email protected]>
Signed-off-by: Andy Kwok <[email protected]>
Signed-off-by: Andy Kwok <[email protected]>
Signed-off-by: Andy Kwok <[email protected]>
Signed-off-by: Andy Kwok <[email protected]>
andy-k-improving
force-pushed
the
ft-ak-iplocation-cmd
branch
from
c972d60 to
b7acfe1
Compare
andy-k-improving
requested review from
ps48,
kavithacm,
derek-ho,
joshuali925,
dai-chen,
YANG-DB,
mengweieric,
Swiddis,
penghuo,
seankao-az,
MaxKsyunz,
Yury-Fridlyand,
anirudha,
forestmvey,
acarbonetto,
GumpacG,
ykmr1224,
LantaoJin and
noCharger
as code owners
Signed-off-by: Andy Kwok <[email protected]>
Signed-off-by: Andy Kwok <[email protected]>
Signed-off-by: Andy Kwok <[email protected]>
Signed-off-by: Andy Kwok <[email protected]>
Signed-off-by: Andy Kwok <[email protected]>
Signed-off-by: Andy Kwok <[email protected]>
|
As per the offline discussion, I have separated out the integration related changes into #3244, in order to minimise the diff. |
acarbonetto
reviewed
Jan 13, 2025
| with: | ||
| product: opensearch | ||
|
|
||
| security-it-linux: |
There was a problem hiding this comment.
Suggested change
| security-it-linux: | |
| geospatial-it-linux: |
| integ-test/build/testclusters/*/logs/* | ||
| integ-test/build/testclusters/*/config/* | ||
| security-it-windows-macos: |
There was a problem hiding this comment.
Suggested change
| security-it-windows-macos: | |
| geospatial-it-windows-macos: |
| matrix: | ||
| java: [21] | ||
| runs-on: ubuntu-latest | ||
| container: |
There was a problem hiding this comment.
seems like container parameter is the only difference between the linux run vs the windows/mac run. It might be nice to combine the two and include an if statement around the container to only set the container when running on ubuntu-latest.
| remoteIntegTestWithSecurity { | ||
| testDistribution = 'archive' | ||
| plugin(getJobSchedulerPlugin()) | ||
| plugin ":opensearch-sql-plugin" | ||
| } | ||
|
|
||
| integTestWithGeo { |
There was a problem hiding this comment.
Suggested change
| integTestWithGeo { | |
| integTestWithGeospatial { |
There was a problem hiding this comment.
does it make sense to have a separate IT test for Geospatial or can we combine everything into the IT tests? I see that IT tests already have job scheduler plugin. Or is the Geospatial test really long?
| @@ -256,11 +289,18 @@ testClusters { | |||
| plugin(getJobSchedulerPlugin()) | |||
| plugin ":opensearch-sql-plugin" | |||
| } | |||
|
|
|||
| @@ -419,6 +419,7 @@ evalFunctionName | |||
| | flowControlFunctionName | |||
| | systemFunctionName | |||
| | positionFunctionName | |||
| | goeipFunctionName | |||
There was a problem hiding this comment.
Suggested change
| | goeipFunctionName | |
| | geoipFunctionName |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Description
Introduce a new PPL command expression
geoip, to perform geo-spatial information lookup with the provided IPv4 || IPv6 addresses, result of the lookup is formatted into a tuple with attribute as key and location detail as value.In this particular setting, SQL plugin will act as a thin client, by relaying the IPEnrichment request to OpenSearch Geo-Spatial plugin, WITHIN the same cluster.
Detail implementation and interface that exposed on Geo-Spatial side can be found:
opensearch-project/geospatial#700
Internally this functionality is achieved by:
OpenSearchFunctionExpressionmarker to identify this is an expression has no default implement on other runtime (Ex: Prometheus)OpenSearchIndexin order to provide an OpenSearch specific handler forevaloperator and its expressions, when OS being used as the storage engine.During runtime, all eval expressions, will being passed to
OpenSearchIndex.visitEval( ), thenOpenSearchEvalOperatorclass will pick up the call, by evaluating allevalexpression as it is, and then handle all occasion ofOpenSearchFunctionExpressionseparately, by reading the function name and argument, and execute the appropriate business logic.Marker class
OpenSearchFunctionExpressionis being used in this case because the actual implementation require runtime OpenSearch client connectivity, howevercoremodule is mean to be generic, hence this workaround is being deployed, by tagging it asOpenSearchFunctionExpressiononcoreand only handle it on theopensearchCradle module .Related Issues
Resolves: #3037
Check List
--signoff.By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.