operator: log op. config cm setting when changed

[subhamkrai]

Description of your changes:

earlier, we're always logging when GetValue method is
called to get operator config values which sometimes
spamming the logs for example ROOK_WATCH_FOR_NODE_FAILURE
keep logging every time 5 min.

Now, we'll store the settings in the map and log only when
map key value is changed.

Which issue is resolved by this Pull Request:
Resolves #12543

Checklist:

• Commit Message Formatting: Commit titles and messages follow guidelines in the developer guide.
• Skip Tests for Docs: If this is only a documentation change, add the label skip-ci on the PR.
• Reviewed the developer guide on Submitting a Pull Request
• Pending release notes updated with breaking and/or notable changes for the next minor release.
• Documentation has been updated, if necessary.
• Unit tests have been added, if necessary.
• Integration tests have been added, if necessary.

[travisn]

But why does this get logged every 5 minutes? Is there node handling code that is triggered every 5 minutes? I don't see where that is. I thought the node handling code was only triggered on node events, not on a timer.

[subhamkrai]

But why does this get logged every 5 minutes? Is there node handling code that is triggered every 5 minutes? I don't see where that is. I thought the node handling code was only triggered on node events, not on a timer.

every time, there is any change in nodes or somehow node watcher is called in nodeLoss scenario is also triggered and the first thing we check is if the configMap setting for nodeLoss is true or not. That's why it keeps logging.

here

rook/pkg/operator/ceph/cluster/watcher.go

Lines 152 to 155 in 7aaf46e

	watchForNodeLoss, err := k8sutil.GetOperatorSetting(ctx, c.context.Clientset, opcontroller.OperatorSettingConfigMapName, "ROOK_WATCH_FOR_NODE_FAILURE", "true")
	if err != nil {
	return pkgerror.Wrapf(err, "failed to get configmap value `ROOK_WATCH_FOR_NODE_FAILURE`.")
	}

I can try moving that code block around L170 or L180 but that will not be right order to check for NodeLoss case.

[Madhu-1]

LGTM, small suggestion on unit test