Skip to content

AWS OpenSearch / ElasticSearch compatibility #1770

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

Closed
jvmlet opened this issue Apr 13, 2021 · 5 comments
Closed

AWS OpenSearch / ElasticSearch compatibility #1770

jvmlet opened this issue Apr 13, 2021 · 5 comments
Labels
status: waiting-for-triage An issue we've not yet triaged

Comments

@jvmlet
Copy link

jvmlet commented Apr 13, 2021

Hello
Given the recent development with ElasticSearch fork, what would be spring-data-elasticsearch roadmap/preferences ?
The day that rest client API become incompatible with OpenSearch is not that far.
Are you going to support both servers (ES and OS) / only one of them (if yes - which one)?

@spring-projects-issues spring-projects-issues added the status: waiting-for-triage An issue we've not yet triaged label Apr 13, 2021
@mp911de
Copy link
Member

mp911de commented Apr 13, 2021

The recent development put the entire community in a difficult situation. It's common practice for data stores to implement an additional communication protocol besides the native one (Apache Geode providing Redis as protocol, AWS DocumentDB with MongoDB protocol support, and many more) which enables the use of existing client-side libraries. The flip side however is that certain assumptions of those connectors are rendered invalid because the remote side behaves differently than expected.

Spring Data Elasticsearch heavily relies on Elasticsearch client libraries. If OpenSearch decides to change the Client API that isn't compatible with Elasticsearch then Spring Data Elasticsearch could not integrate with that particular feature or break entirely.

Since future development isn't clear at this point and this project is driven by the community, it's always good to get involved and help the project to drive its evolution.

@jvmlet
Copy link
Author

jvmlet commented Apr 13, 2021

The compatibility might also be broken at the point ES decides to expose additional methods over rest in future versions (and DATAES integrates them ). Invoking these endpoints will definitely won't work if executed against OS server.

@mp911de
Copy link
Member

mp911de commented Apr 13, 2021

Indeed, that could break OS users. OpenSearch was never a goal of this project, frankly speaking. In an extreme case, one would have to either fork this project and adapt it to OpenSearch or contributors would help to rewrite the codebase so that the underlying transport/API/… would be agnostic.

In any case, we will have to see what the future holds.

@sothawo
Copy link
Collaborator

sothawo commented Apr 13, 2021

For the time being we should watch how OpenSearch evolves. As long as the REST APIs are compatible, there is no problem for Spring Data Elasticsearch sticking to ES client libs. Problems will come when there is a functional or API drift between the two. We then must decide to either support only one, or add an abstraction layer above both - which would mean that we could only support the common feature set. This could get ugly.

But for the time being, we stick to ES and have an eye on what is going on with OS. First thing I think would make sense is wait for a docker image to be available for OpenSearch and use that to run the integration tests against.

@sothawo
Copy link
Collaborator

sothawo commented Apr 17, 2021

I think we can close this issue. Currently we cannot do more than monitor how Opensearch evolves.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status: waiting-for-triage An issue we've not yet triaged
Projects
None yet
Development

No branches or pull requests

4 participants