Description of problem: The api listing the OSDs does not contains the details like name, size etc of the underlying storage device. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. Create a ceph cluster 2. Add OSDs to the cluster 3. Access the ceph api /api/v2/cluster/{fsid}/osd?format=json Actual results: There are no details of underlying details in the list Expected results: The underlying storage device details like UUID, Name and Size should be populated Additional info:
This is going to be an RFE since the only two details we expose are: backend_partition_path backend_device_node
I can provide anything in this structure { "id": 49, "arch": "x86_64", "back_addr": "172.21.5.114:6826\/12904", "backend_filestore_dev_node": "unknown", "backend_filestore_partition_path": "unknown", "ceph_version": "ceph version 9.0.3-2033-g3570ec6 (3570ec612a6e85169007e50533ea56c152a23f8e)", "cpu": "Intel(R) Xeon(R) CPU X3430 @ 2.40GHz", "distro": "Ubuntu", "distro_codename": "trusty", "distro_description": "Ubuntu 14.04.3 LTS", "distro_version": "14.04", "filestore_backend": "xfs", "filestore_f_type": "0x58465342", "front_addr": "172.21.5.114:6825\/12904", "hb_back_addr": "172.21.5.114:6827\/12904", "hb_front_addr": "172.21.5.114:6828\/12904", "hostname": "mira049", "kernel_description": "#105-Ubuntu SMP Mon Sep 21 18:50:58 UTC 2015", "kernel_version": "3.13.0-65-generic", "mem_swap_kb": "16766972", "mem_total_kb": "16425176", "os": "Linux", "osd_data": "\/var\/lib\/ceph\/osd\/ceph-49", "osd_journal": "\/var\/lib\/ceph\/osd\/ceph-49\/journal", "osd_objectstore": "filestore" } in the osd list or detail endpoint It's a bug in ceph where "backend_filestore_dev_node": "unknown", I cannot estimate how long it will take to fix. perhaps a workaround would be to look at the fields osd_data and osd_journal with salt and map the device
Looking at this it does not look like we can figure out from which physical disk the OSD was created. That is the main data we are looking at during import cluster flow.
Without disk details available for the OSD, we would not be able to sync details like storage profile / disk profile and even I feel crush details. @Nishanth, you can add to this if my understanding is not very true.
@Gregory, if you can provide data and journal partitions for the OSD, we might be able to figure out the physical disk using lsblk command. Do the required changes in calamari for the same.
Development Management has reviewed and declined this request. You may appeal this decision by reopening this request.
You mean even the mount point would not be provided? In that case major feature import cluster cannot be done..
Sorry Shubhendu I dev_ackd - by mistake
With osd_data and osd_journal USM tries to figure out underlying disks now.
The osd_data and osd_journal values are now displayed. moving the defect to verified state. Verified on: calamari-server-1.4.0-0.12.rc15.el7cp.x86_64 ceph version 10.2.1-18.el7cp
Bara, The doc text looks fine. RH Storage Console does use these to infer what devices are backing the OSD
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2016:1755