We need a way to surface Elasticsearch cluster level information to the ElasticsearchCluster resource. Without teaching navigator-controller how to interact with Elasticsearch itself, which is a pattern we've avoided thus far, the elasticsearchcluster.status.clusterHealth (or equivalent) field needs to be updated appropriately.
The 'master' Pilot could update this field, but we'd then need to also ensure navigator-controller and the master pilot don't flip-flop performing updates to the status block of the resource.
I'm fairly sure a similar pattern exists between kube-controller-manager and kubelet, where both update the node.status block. This could perhaps be done by namespacing all of the fields the pilot is responsible for under a single yaml key (e.g. elasticsearchcluster.status.cluster.health.
This information could then also be used to influence the scale-up/scale-down decision or any cluster 'shape' change decisions.
We need a way to surface Elasticsearch cluster level information to the ElasticsearchCluster resource. Without teaching navigator-controller how to interact with Elasticsearch itself, which is a pattern we've avoided thus far, the
elasticsearchcluster.status.clusterHealth(or equivalent) field needs to be updated appropriately.The 'master' Pilot could update this field, but we'd then need to also ensure
navigator-controllerand the master pilot don't flip-flop performing updates to the status block of the resource.I'm fairly sure a similar pattern exists between kube-controller-manager and kubelet, where both update the
node.statusblock. This could perhaps be done by namespacing all of the fields the pilot is responsible for under a single yaml key (e.g.elasticsearchcluster.status.cluster.health.This information could then also be used to influence the scale-up/scale-down decision or any cluster 'shape' change decisions.
/kind feature /area elasticsearch
/cc @wallrj