I have automated tests that make use of the Rest High Level Client (RHLC) to communicate with an HA Elasticsearch cluster created using EsIntegTestCase to run the cluster in the JVM/process. I was previously testing against an es7 server cluster and now want to upgrade to es8 with RHLC v7 in compatibility mode which is supported.
The problem seems to be that RHLC v7 APIs are not compatible with Elasticsearch v8 (e.g., org.elasticsearch.action.admin.indices.flush.SyncedFlushRequest and org.elasticsearch.client.Client do not exist in elasticsearch v8) and both libraries will be in the same process if testing via EsIntegTestCase. That's because EsIntegTestCase is in org.elasticsearch.test:framework and its transitive dependency is the elasticsearch library. So if I want to bring up a test server cluster in v8 I need test:framework v8 which pulls in elasticsearch library v8, which is incompatibile with RHLC v7.
Can anyone confirm this problem? Is there a workaround?
Alternatively, is there a test container equivalent that can easily spin up an HA cluster? I doubt there's anything as fully-featured as EsIntegTestCase.
It seems like my only option is to use testcontainers / containers (maybe docker-compose) to spin up a cluster to replace EsIntegTestCase and then spend a lot of effort reproducing the functionality of EsIntegTestCase that I need.
Do I have any other options? TIA
P/S this is a similar topic to my recent post where it was determined that EsNode (another class that helps bring up an Elasticsearch server in the same process / embedded mode) is no longer supported. However, unless I'm not mistaken, EsIntegTestCase is still supported but it shares a commonality with EsNode in that both spin up servers in the same process. So I think it will have the same problems. But since this is still supported, afaik, I am hoping there's a solution.
That's somewhat what I do in some of my projects.
Using docker behind the scene or have a "always on" elastic cluster running on my machine or on cloud.
The other option I can imagine would be to use instead the new Java client but I guess you don't want this yet.
Thanks for your reply. Actually given how difficult migration with RHLC has proven to be (pretty disappointed bc the migration guide made it sound so easy!), I'm starting to think it would've been better to just go to the java client. I don't want to deconstruct all my test infrastructure (a lot of tests dependent on Node and EsIntegTestCase) and convert them to test containers for a few quarters/releases and then when I end up using the java client I'd probably want to come back to the supported/idiomatic Node and EsIntegTestCase.
This is also what we do internally within the Elasticsearch team.
EsIntegTestCase is only used for cases where we actually need to mess with the internals of the cluster. Anything that can be tested via the Rest API is tested using a cluster that is orchestrated via docker.
It depends what you mean by "supported". It is maintained, and there are cases where it is useful outside of the ES project itself (e.g. plugins developers) but we don't intend it to be used to test rest clients/external apps.
So say we transition OFF of EsIntegTestCase...in a year, when my team transitions off of using RHLC in compatibility mode to using the java client, at that point would you all recommend continuing to use elasticsearch nodes/clusters to test against or would you recommend using EsIntegTestCase?
I think we are mainly using the EsIntegTestCase to test more complex restart/shutdown/failover scenarios.
Apache, Apache Lucene, Apache Hadoop, Hadoop, HDFS and the yellow elephant
logo are trademarks of the
Apache Software Foundation
in the United States and/or other countries.