Error - Invalid or missing build flavor [oss] for ES server upgrade to 7.10

Elastic Stack Elasticsearch
,
1

Hi,

I upgraded ES server on AWS from 6.8 to 7.10 (this is the latest offered for now). Until now I have been using Restclient 7.17.x. After upgrading the server I started getting -
Note: This works fine on docker locally with 7.10.1

org.elasticsearch.ElasticsearchException: Invalid or missing build flavor [oss]
at org.elasticsearch.client.RestHighLevelClient.performClientRequest(RestHighLevelClient.java:2701)
at org.elasticsearch.client.RestHighLevelClient.internalPerformRequest(RestHighLevelClient.java:2171)
at org.elasticsearch.client.RestHighLevelClient.performRequest(RestHighLevelClient.java:2137)
at org.elasticsearch.client.RestHighLevelClient.performRequestAndParseEntity(RestHighLevelClient.java:2105)
at org.elasticsearch.client.RestHighLevelClient.bulk(RestHighLevelClient.java:620)

GET / for above is

{
  "name" : "omitted",
  "cluster_name" : "omitted",
  "cluster_uuid" : "omitted",
  "version" : {
    "number" : "7.10.2",
    "build_flavor" : "oss",
    "build_type" : "tar",
    "build_hash" : "unknown",
    "build_date" : "2023-12-20T06:48:37.663499Z",
    "build_snapshot" : false,
    "lucene_version" : "8.7.0",
    "minimum_wire_compatibility_version" : "6.8.0",
    "minimum_index_compatibility_version" : "6.0.0-beta1"
  },
  "tagline" : "You Know, for Search"
}

To get around this I tried to switch to using Java API client 7.17.21 as Elasticsearch client is deprecated. But that gave me header error on Docker

co.elastic.clients.transport.TransportException: 
node: http://aws-local:9300/, status: 200, 
[es/bulk] Missing [X-Elastic-Product] header. 
Please check that you are connecting to an Elasticsearch instance, and that any networking filters are preserving that header.

GET / for above is

{
  "name" : "63bf0fa45556",
  "cluster_name" : "docker-cluster",
  "cluster_uuid" : "w67XjXmoQ72qyj0TPB9ZjQ",
  "version" : {
    "number" : "7.10.1",
    "build_flavor" : "default",
    "build_type" : "docker",
    "build_hash" : "1c34507e66d7db1211f66f3513706fdf548736aa",
    "build_date" : "2020-12-05T01:00:33.671820Z",
    "build_snapshot" : false,
    "lucene_version" : "8.7.0",
    "minimum_wire_compatibility_version" : "6.8.0",
    "minimum_index_compatibility_version" : "6.0.0-beta1"
  },
  "tagline" : "You Know, for Search"
}
  1. Is Java API Client supported with server version of 7.10?
  2. If no then what are my options for this server upgrade?
2

Welcome!

Your best option is to switch to Cloud by Elastic, also available if needed from AWS Marketplace.

Cloud by elastic is one way to have access to all features, all managed by us. Think about what is there yet like Vector Search, Security, Monitoring, Reporting, ES|QL, Canvas, Maps UI, Alerting and built-in solutions named Observability, Security and what is coming next :slight_smile: ...

Anyway 7.10 is totally outdated and IMHO unsecured. So you should not run this version. Switching to at least 7.17 or better 8.13 is the best option.

If you don't want to, you need to downgrade the client and use the exact same version for the client and the server. 7.10 in your case.

Also note that the High Level Rest Client has been now deprecated in 7.x and removed in 8.x.

3

Hi David,

Thanks for the advise. For now we cannot move out of AWS.

If you don't want to, you need to downgrade the client and use the exact same version for the client and the server. 7.10 in your case.

There is no Java API Client available for matching server version 7.10.2 - minimum version is 7.15
mvnrepository -> artifact/co.elastic.clients/elasticsearch-java

4

That's why I mentioned this: AWS Marketplace

You can stay on AWS and use AWS billing but create a more modern and true Elasticsearch cluster.

That's true. So you need to use the old deprecated High Level Rest client 7.10.2.

That's why I'm really advicing to switch to Elasticsearch 7.17 or better 8.13.

5

Deprecating dependency for high-level-rest-client to 7.10.x worked. Thanks!

6

Great that it "works", but definitely that is not the best option. I think your cluster does not benefit from all the security patches... :pensive: