Describe the feature you'd like to have.
The operator should log all of its actions to stdout to help diagnose problems.
What is the value to the end user? (why is it a priority?)
While the operator is intended to automate the management of a Gluster cluster, its actions must be both observable and understandable. An admin will hesitate to allow automated management if it is difficult to understand what the operator is doing and why.
How will we know we have a good solution? (acceptance criteria)
Logs should go to stdout in a standard format in the operator container to be picked up by the logging (EFK) stack
All "configuration altering" actions should be logged
The reason for the action should also be logged
Additional context
I expect this to be the main source of data for answering "why did it (not) do that?" This will become increasingly important as the sophistication of the operator's algorithms increases.
Describe the feature you'd like to have. The operator should log all of its actions to stdout to help diagnose problems.
What is the value to the end user? (why is it a priority?) While the operator is intended to automate the management of a Gluster cluster, its actions must be both observable and understandable. An admin will hesitate to allow automated management if it is difficult to understand what the operator is doing and why.
How will we know we have a good solution? (acceptance criteria)
Additional context I expect this to be the main source of data for answering "why did it (not) do that?" This will become increasingly important as the sophistication of the operator's algorithms increases.