Client/Coordinating nodes with the ES helm chart?

[jinja2]

Hi, the elasticsearch chart in the community repo spins up client nodes as deployment. Looking at elastic's ES chart, if all 3 roles are set to false and cross cluster search is disabled through esConfig, the corresponding statefulset will compose of coordinating nodes(?)
Can you please explain why a statefulset is preferred over deployment for coordinating nodes and why does it need a persistent volume claim? Or is this chart not supposed to be used for client-only node? I looked through the examples and readme but didn't see any mention of coordinating only nodes. TIA

[rwittrick]

Also, coordinator nodes do not need a cluster_health of green, they can cope with yellow. If a coordinator node is restarted while the cluster is yellow, the readiness probe fails, failing kibana or beats being able to write.

[jordansissel]

coordinator nodes do not need a cluster_health of green

I think the node readinessProbe could be best discussed in a separate issue, and affects all roles not just coordinators. Can you open a separate issue?

[jordansissel]

Can you please explain why a statefulset is preferred over deployment for coordinating nodes

"preferred" sounds like it assumed this was an explicit choice, and I'm not sure it was.

In Elasticsearch, a coordinator node is a node with all other roles disabled. The chart today doesn't have any special handling for the case you describe such as "When all roles are disabled, do X, Y, and Z differently".

It's possible that we only need PVCs when data or master roles are enabled (I dont' think ML or ingest roles need persistent disk).

I've personally never used coordinating nodes (in ~9 years of using Elasticsearch), so it's not something I think about when I'm building things. I can't speak for @Crazybus or @jethr0null's experiences in this area, though. I'm glad to see others are thinking about this, though, so we can improve the chart together :)

[Crazybus]

Can you please explain why a statefulset is preferred over deployment for coordinating nodes and why does it need a persistent volume claim?

It wasn't a conscious decision to do this for coordinating nodes. I have the same response as @jordansissel in that I have never had a need for them personally so it wasn't something that was part of the design. Luckily though it seems it should be very simple to make this configuration possible.

Would you have any objections to coordinating nodes being statefulsets without a persistent volume claim? The advantage with keeping all node types using statefulsets is that it helps to keep the configuration and features consistent between all possible Elasticsearch node combinations. If we were to implement deployments for non-data requiring combinations of node roles then all changes would need to be duplicated into the statefulset and the deployment templates. It helps to keep the chart as flexible as possible and reduce the complexity of it.

Having a look through the node types documentation it seems like only master and data roles require persistent data.

So requesting and mounting the pvc should only be done if both node.master and node.data are set to false. It's important to explicitly check for false as it is also possible for a user to not specify node.master or node.data which will then result in Elasticsearch using the default setting of true for both of them.

[jinja2]

@Crazybus @jordansissel thanks guys for your responses, sorry, i forgot to update this issue... For now, we have customized our ES chart to be able to spinup coordinating nodes as deployments. The main reason for using deployments is the ease of rolling updates (we can configure surge).
I am going to close this issue for now.

[Crazybus]

I have opened #114 to make deploying a statefulset without persistent data possible.