Bug 1314692 - RFE: Device details not available as part of OSD listing apis
Summary: RFE: Device details not available as part of OSD listing apis
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Ceph Storage
Classification: Red Hat
Component: Calamari
Version: 1.2.3
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: rc
: 2.0
Assignee: Christina Meno
QA Contact: Harish NV Rao
Bara Ancincova
URL:
Whiteboard:
Depends On:
Blocks: 1291304 1322504
TreeView+ depends on / blocked
 
Reported: 2016-03-04 09:18 UTC by Shubhendu Tripathi
Modified: 2016-08-23 19:33 UTC (History)
6 users (show)

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.
Clone Of:
Environment:
Last Closed: 2016-08-23 19:33:22 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2016:1755 normal SHIPPED_LIVE Red Hat Ceph Storage 2.0 bug fix and enhancement update 2016-08-23 23:23:52 UTC

Description Shubhendu Tripathi 2016-03-04 09:18:27 UTC
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 Christina Meno 2016-03-10 05:23:41 UTC
This is going to be an RFE since the only two details we expose are: 
backend_partition_path 
backend_device_node

Comment 3 Christina Meno 2016-03-24 22:41:19 UTC
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 06:42:50 UTC
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 04:15:12 UTC
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 10:03:43 UTC
@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 Program Management 2016-04-08 04:45:32 UTC
Development Management has reviewed and declined this request.
You may appeal this decision by reopening this request.

Comment 8 Shubhendu Tripathi 2016-04-08 04:52:04 UTC
You mean even the mount point would not be provided? 
In that case major feature import cluster cannot be done..

Comment 9 Christina Meno 2016-04-08 17:55:11 UTC
Sorry Shubhendu I dev_ackd - by mistake

Comment 12 Shubhendu Tripathi 2016-06-13 10:17:08 UTC
With osd_data and osd_journal USM tries to figure out underlying disks now.

Comment 13 Harish NV Rao 2016-06-13 10:18:59 UTC
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 Christina Meno 2016-06-20 17:50:17 UTC
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 19:33:22 UTC
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.