canonical / elasticsearch-k8s-operator Goto Github PK

According the the Graylog docs [0], we need to explicitly set discovery.zen.minimum_master_nodes to be NUM_NODES / 2 + 1. If it is less than this, it is possible that two ES leader nodes are elected by different subsets of nodes.

However, we should be aware that this is not necessary in ES 7.x [1].

[0] https://docs.graylog.org/en/3.2/pages/configuration/elasticsearch.html#avoiding-split-brain-and-shard-shuffling
[1] https://www.elastic.co/guide/en/elasticsearch/reference/current/breaking-changes-7.0.html#breaking_70_discovery_changes

The current implementation of this Elasticsearch charm protects against "Split Brain" problem but dynamically setting the minimum master nodes parameter. However if the administrator chooses to deploy exactly two nodes then a network partition can still lead to a split brain because each node will find it has quorum (1 minimum master node). How do we protect against this problem ? Shall we explicitly document this in the README ? Is there a better way ?

After recent commit that used dynamic settings to solve split brain problem, deploying Elasticsearch charm shows transient hook failed errors. This errors are transient and do resolve themselves, possibly in subsequent execution of the same hook. Is this behaviour acceptable ?. What is causing this behaviour ?

Use Case

A system operator would like to increase the amount of storage available to Elasticsearch nodes.

Create the framework to support dynamic settings in elasticsearch.yml and reload them.

A recent bug required the use of a busy loop in the Charm code to fix the problem. This was because there was no obvious way to respond to a event in the application (Elasticsearch) life cycle. The particular event was the discovery of a new node by an existing Elasticsearch cluster. Elasticsearch itself has the ability to raise alerts in response to configurable events (perhaps even the discovery of a new node ?). However there was no obvious way to translate such an alert into a Juju event that the charm can handle. Hence the question, is there a better way to tie the discovery of a new Elasticsearch cluster node to a Charm event handler ?

Is it possible to have unicast_hosts.txt updated without restarting the pod.

Use Case

Clients that need to provide logs/data to Elasticsearch need an interface relation defined and implemented.

Configure Elasticsearch charm to be secure by default.