| No I disagree on considering "yellow" a sane default. If the cluster is yellow it's very possible that it's still starting and we should give it a chance to form... yes this is an edge case but for this specific edge you won't have to wait for many seconds, so it's just about being "user friendly" for people starting up a bunch of VMs (i.e. clouds).
Yet if the cluster is "yellow" because something is really wrong, then allowing to write to it is as good as the unsafe-by-default on MongoDB which we've laughed about. I do agree that the user might be happy with writing on one replica only - definitely a valid scenario - but he/she has plenty of configuration options to make this explicit in the Elasticsearch configuration (i.e. ES would report "green" in a more relaxed configuration). +1 to regularly check for the cluster health. I'm sure I already mentioned that this would be needed eventually.. it's way more complex though, as we've already started so what are we going to do with the changes? Sending runtime exceptions up seems not very nice. My question still stands: why should I prefer reconfiguring an Hibernate Search property to "write on yellow" rather than reconfigure Elasticsearch?
For example, if all you want is to start a demo you probably want to disable discovery altogether.. or you risk connecting to someone else on the conference wifi, or countless other issues.. not least, it will start faster. This is a good "demo configuration" which I tuned myself: https://github.com/hibernate/hibernate-search/blob/master/elasticsearch/elasticsearchconfiguration/elasticsearch.yml |