Description of problem (please be detailed as possible and provide log snippests): Currently for any unacceptable values updation in rook-ceph-config configmap no error logs are provided and silently the default values are considered as per rook design. This maybe confusing from customer point of view. Version of all relevant components (if applicable): OCP version --- 4.12.0-0.nightly-2022-10-05-053337 OCS version --- 4.12.0-74 Does this issue impact your ability to continue to work with the product (please explain in detail what is the user impact)? No Is there any workaround available to the best of your knowledge? No Rate from 1 - 5 the complexity of the scenario you performed that caused this bug (1 - very simple, 5 - very complex)? 1 Can this issue reproducible? 1 Can this issue reproduce from the UI? Yes If this is a regression, please provide more details to justify this: Yes Steps to Reproduce: 1. Update CSI_ENABLE_METADATA flag with any value other than true/false example: oc patch cm rook-ceph-operator-config -n openshift-storage -p $'data:\n "CSI_ENABLE_METADATA": "meta"' 2. Check the value updated successfully oc get cm rook-ceph-operator-config -o yaml apiVersion: v1 data: CSI_ENABLE_METADATA: meta 3. Check the rook log generated Actual results: Currently for any unacceptable values updation in rook-ceph-config configmap no error logs are provided and silently the default values are considered as per rook design. This maybe confusing from customer point of view. Expected results: Some kind of error logs can be displayed in rook and an intimation of the default value is been considered. Additional info:
The CRDs have a schema for validation, but this configmap is just a simple list of key-value pairs, with no schema attached. If wondering why a setting wasn't applied you anyway need to look in the operator log to see the value you set and compare it to the docs for what you should set. Yes, it would be better see an error in the log, but effectively implementing a schema for the configmap seems more effort than it's worth.
(In reply to Travis Nielsen from comment #3) > The CRDs have a schema for validation, but this configmap is just a simple > list of key-value pairs, with no schema attached. > > If wondering why a setting wasn't applied you anyway need to look in the > operator log to see the value you set and compare it to the docs for what > you should set. Yes, it would be better see an error in the log, but > effectively implementing a schema for the configmap seems more effort than > it's worth. Yes having schema is not worth, but we an log and user can at-least see the error in the operation logs that should be fine in think.
After discussing offline with Madhu we feel without a full schema we will have many corner cases that will be challenging to cover. Generally validating all of these settings is not a goal. But please reopen if you feel there is a common case that has been difficult to troubleshoot that really should be fixed.