Bug 1314692 - RFE: Device details not available as part of OSD listing apis
RFE: Device details not available as part of OSD listing apis
Status: CLOSED ERRATA
Product: Red Hat Ceph Storage
Classification: Red Hat
Component: Calamari (Show other bugs)
1.2.3
Unspecified Unspecified
high Severity high
: rc
: 2.0
Assigned To: Gregory Meno
Harish NV Rao
Bara Ancincova
: Reopened
Depends On:
Blocks: 1291304 1322504
  Show dependency treegraph
 
Reported: 2016-03-04 04:18 EST by Shubhendu Tripathi
Modified: 2016-08-23 15:33 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
.The Ceph API contains more details about OSD nodes The Ceph API now includes locations of the data that is stored on an OSD and the path to the OSD journal. The API is accessible from `/api/v2/cluster/<fsid>/osd?format=json`. Also, the Red Hat Storage Console uses this information to infer what devices the OSD daemons use.
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-08-23 15:33:22 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Shubhendu Tripathi 2016-03-04 04:18:27 EST
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:
Comment 2 Gregory Meno 2016-03-10 00:23:41 EST
This is going to be an RFE since the only two details we expose are: 
backend_partition_path 
backend_device_node
Comment 3 Gregory Meno 2016-03-24 18:41:19 EDT
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
Comment 4 Shubhendu Tripathi 2016-03-25 02:42:50 EDT
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.
Comment 5 Shubhendu Tripathi 2016-03-28 00:15:12 EDT
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.
Comment 6 Shubhendu Tripathi 2016-04-04 06:03:43 EDT
@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.
Comment 7 RHEL Product and Program Management 2016-04-08 00:45:32 EDT
Development Management has reviewed and declined this request.
You may appeal this decision by reopening this request.
Comment 8 Shubhendu Tripathi 2016-04-08 00:52:04 EDT
You mean even the mount point would not be provided? 
In that case major feature import cluster cannot be done..
Comment 9 Gregory Meno 2016-04-08 13:55:11 EDT
Sorry Shubhendu I dev_ackd - by mistake
Comment 12 Shubhendu Tripathi 2016-06-13 06:17:08 EDT
With osd_data and osd_journal USM tries to figure out underlying disks now.
Comment 13 Harish NV Rao 2016-06-13 06:18:59 EDT
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
Comment 15 Gregory Meno 2016-06-20 13:50:17 EDT
Bara,

The doc text looks fine.
RH Storage Console does use these to infer what devices are backing the OSD
Comment 18 errata-xmlrpc 2016-08-23 15:33:22 EDT
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

Note You need to log in before you can comment on or make changes to this bug.