Elasticsearch index alias opt-out?

[yrodiere]

@aaronloes

I know the use of aliases is good, and I was part of the request for their support (Hibernate Search 6 Index Aliases), but there is no requirement that I am aware of in Elasticsearch that forces the use of aliases.

While not required, they are necessary for several important maintenance features. As explained here, aliases are necessary if you want to execute zero-downtime maintenance operations later on. As this is a rather obscure configuration option for most users, it was decided to make aliases the default, to make sure that everyone starts with a future-proof setup. I’m sure you are painfully aware how starting out without aliases can be once you end up having to add these aliases…

@aaronloes

Is there a way to avoid the use of aliases and write to the index directly similar to what was done in Beta2? Or will I need to go through my existing indexes and add aliases for them to get my application to work again?

Yes, in Hibernate Search 6.0.0.CR1 you must have aliases for all your indexes. Upgrading from Beta2 to the final release will unfortunately require some changes to your application.
That’s definitely not the kind of change we will introduce now after 6.0 becomes stable, but during the beta, it was deemed a necessary and acceptable change.

Several solutions:

1. Drop your indexes completely, have Hibernate Search re-create them, and re-populate them using mass indexing. While it’s a bit extreme, it’s also the easiest solution.
2. OR start your application with the property hibernate.search.schema_management.strategy set to create-or-update. Hibernate Search will add the aliases itself. Be careful though, there are risks, so you should try it on a copy of your production environment first. Don’t forget to set the property hibernate.search.schema_management.strategy back to a safer value afterwards.
3. OR use the createOrUpdate operation on the schema management API. Same risks as above.
4. OR run a script manually. Assuming you don’t have any of the aliases needed by Hibernate Search right now, this sh script should do:

   ES=http://localhost:9200
   curl -XPOST "$ES/_aliases" -H "Content-Type: application/json" -d"{\"actions\": [$(curl "$ES/_cat/indices?h=index" | sed -E 's/.*/{"add":{"index":"\0", "alias":"\0-read", "is_write_index": false}},{"add":{"index":"\0", "alias":"\0-write", "is_write_index": true}}/;2,$i ,')]}"
   curl -XGET http://localhost:9200/_cat/aliases\?pretty
   

@aaronloes

From a option side of things, I don’t think Hibernate Search for Elasticsearch should force a usage pattern with Elasticsearch. I think it should provide reasonable defaults but allow the developer to choose how they want Elasticsearch to be configured, written to, and queried. Having data in Elasticsearch provides much more use (e.g. analytics, data visualizations, etc.) other than just being able to perform search as part of application features. Being able to disable schema management is just one part of this.

Ideally, yes it should allow deep customization. Practically, there are limits to the amount of different configurations we can maintain properly and test regularly, especially when some of them (this one in particular) have effects on every single request sent by Hibernate Search. So we start small, and expand with customization options as necessary. That’s what we did in this case.