Description of problem (please be detailed as possible and provide log snippests): When getting the config map of rook-ceph-mon-endpoints, the data mapping values of the "node" is null instead of the node name. Version of all relevant components (if applicable): OCP 4.8, OCS 4.8 latest build. Does this issue impact your ability to continue to work with the product (please explain in detail what is the user impact)? A little. I get the wrong rook ceph mon endpoints data mapping values. 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? Yes. Can this issue reproduce from the UI? No. If this is a regression, please provide more details to justify this: Yes. The values weren't null in an older version of OCS 4.8. Steps to Reproduce: Run the command "oc -n openshift-storage get ConfigMap rook-ceph-mon-endpoints -n openshift-storage -o yaml | grep mapping" from the cli. You will get the output of the config map of the rook-ceph-mon-endpoints data mapping. Actual results: The line of the data mapping shows: mapping: '{"node":{"a":null,"b":null,"c":null}}' Expected results: The line of the data mapping should show the values of the node names. something like this output: 'mapping': '{"node":{"a":{"Name":"compute-0","Hostname":"compute-0","Address":"10.1.161.135"},"b":{"Name":"compute-1","Hostname":"compute-1","Address":"10.1.161.90"},"c":{"Name":"compute-2","Hostname":"compute-2","Address":"10.1.161.91"}}}' Additional info: I used a vSphere dynamic cluster with OCP 4.8, OCS 4.8. Link to Jenkins job: https://ocs4-jenkins-csb-ocsqe.apps.ocp4.prod.psi.redhat.com/job/qe-deploy-ocs-cluster/5569/ Versions of all components: OCP version: Client Version: 4.8.0-0.nightly-2021-09-11-042202 Server Version: 4.8.0-0.nightly-2021-08-29-075226 Kubernetes Version: v1.21.1+9807387 OCS verison: ocs-operator.v4.8.1-177.ci OpenShift Container Storage 4.8.1-177.ci Succeeded cluster version NAME VERSION AVAILABLE PROGRESSING SINCE STATUS version 4.8.0-0.nightly-2021-08-29-075226 True False 14d Cluster version is 4.8.0-0.nightly-2021-08-29-075226 Rook version rook: 4.8-169.9a9db5f.release_4.8 go: go1.16.6
Santosh, Any update on your findings?
This looks like an expected rook behavior. `mapping` value is stored as nil when Host Networking is not enabled or when `mon.VolumeClaimTemplate` is set. https://github.com/rook/rook/blob/0d8fd9d8a47799fbb2607fded7bab757fee2fd6a/pkg/operator/ceph/cluster/mon/mon.go#L849-L863 Might close this BZ as not a bug after confirming the above behavior.
Right, now I'm remembering... Mons will have a node assignment from Rook if using host networking or if the mons are using the dataDirHostPath. But those conditions are false for OCS, and we rely purely on the K8s scheduler to assign the mons to a node. Since the mons are backed by a PV, they are as portable as their PVs allow, and are not technically bound to a node unless the PV is also bound to the node. So it is expected that the configmap would contain null in this case. Closing as by design.