The operator did not reliably inform me, that the Opensearch Cluster was unhealthy. Despite the OS statefulset being misconfigured, resulting in it never becoming ready the OpenSearchCluster CR never reflected this state. As I was monitoring the Pods directly for issues I never realised the issue was in fact with the statefulset config (misconfiguration caused by myself).
How can one reproduce the bug?
Create an OS CR with a misconfiguration of the statefulset, e.g. accessMode: ReadWriteOnce instead of accessModes: [ReadWriteOnce].
Deploy the CR
Watch the bootstrap, dashboard and initJob Pods start, log errors and restart endlessly.
Check the Status of the CR, where there is no indication of the fault or it's origin.
What is the expected behavior?
I would expect the status of the OS CR to reflect the error state of the dependent statefulset. I don't expect the operator to sanity check the statefulset configuration, but surfacing the errors of generated resources on the CR would be very beneficial.
dblock
commented
1 week ago
What is the bug?
The operator did not reliably inform me, that the Opensearch Cluster was unhealthy. Despite the OS statefulset being misconfigured, resulting in it never becoming ready the OpenSearchCluster CR never reflected this state. As I was monitoring the Pods directly for issues I never realised the issue was in fact with the statefulset config (misconfiguration caused by myself).
How can one reproduce the bug?
accessMode: ReadWriteOnceinstead ofaccessModes: [ReadWriteOnce].What is the expected behavior?
I would expect the status of the OS CR to reflect the error state of the dependent statefulset. I don't expect the operator to sanity check the statefulset configuration, but surfacing the errors of generated resources on the CR would be very beneficial.
What is your host/environment?
Azure Linux, AKS, OS Operator 2.5.1