Unify Elasticsearch configuration for Elasticsearch clients and Hibernate Search

[yrodiere]

Description

For Hibernate ORM, we have the concept of (JDBC) "datasource".
For Hibernate Reactive, we have the concept of (non-JDBC) "datasource".
Those allow users to specify JDBC urls (or other, in the case of non-JDBC) in a way that is independent from Hibernate ORM, so that you can use only JDBC, or only Hibernate, or both, but in all cases you only configure the datasource once.

However, if you use both Hibernate Search and an Elasticsearch client, you'll have to configure the Elasticsearch URL and client options twice:

• once for the Elasticsearch clients
• once for Hibernate Search

That's not very practical.

EDIT: And it also complicates the Elasticsearch dev-service implementation. In particular we currently only support starting dev-services for the default Elasticsearch backend in Hibernate Search, not for named backends, because that would be complicated to implement.

Maybe we could unify that, shoving everything under the Elasticsearch client?

Implementation ideas

A relatively low-effort solution would be to simply have Hibernate Search look for the Elasticearch client configuration, but still create its own, separate client.

A more complicated solution would be to have Hibernate Search use a low-level Elasticsearch client created by Quarkus. That would require changes (new SPIs or configuration options) in Hibernate Search, though. EDIT: See https://hibernate.atlassian.net/browse/HSEARCH-4683

Things to be careful about with this solution:

• Advanced client features in Hibernate Search:
  • The discovery (sniffer) might be easy to expose in the elasticsearch-rest-common extension.
  • AWS signing (in the Quarkiverse) might be a bit more complex. Maybe we should move the part specific to the Elasticsearch client out of Hibernate Search into a separate project?

Things to be careful about regardless of the solution:

• Backwards compatibility: the current configuration properties in the Hibernate Search extension will have to continue to work.
• Documentation... including the migration guide. That'll be a mess, but hopefully for the better.

[quarkus-bot]

/cc @gsmet, @loicmathieu

[loicmathieu]

I agree we should consolidate the two.
An inspiration may be reactive messaging Kafka which support both configuration, under quarkus.kafka.* and mp.reactive.[...].*.

So when configuring Hibernate search, if Elasticsearch stuff are not configured it should look under quarkus.elasticsearch configurations, or, as you suggest, for an existing rest low level client in Arc.