On 12/7/22 12:15, Alwin Antreich wrote:
Hi,
December 6, 2022 4:47 PM, "Aaron Lauterer" <a.laute...@proxmox.com> wrote:
To get more details for a single OSD, we add two new endpoints:
* nodes/{node}/ceph/osd/{osdid}/metadata
* nodes/{node}/ceph/osd/{osdid}/lv-info
As an idea for a different name for lv-info,
`nodes/{node}/ceph/osd/{osdid}/volume`? :)
Could be done, as you would expect to get overall physical volume infos from it,
right? So that the endpoint won't change, once the underlying technology changes?
[...]
Possible volumes are:
* block (default value if not provided)
* db
* wal
'ceph-volume' is used to gather the infos, except for the creation time
of the LV which is retrieved via 'lvs'.
You could use lvs/vgs directly, the ceph osd relevant infos are in the lv_tags.
IIRC, and I looked at it again, mapping the OSD ID to the associated LV/VG would
be a manual lookup via /var/lib/ceph/osd/ceph-X/block which is a symlink to the
LV/VG.
So yeah, would be possible, but I think a bit more fragile should something
change (as unlikely as it is) in comparsion to using ceph-volume.
I don't expect these API endpoints to be run all the time, and am therefore okay
if they are a bit more expensive regarding computation resources.
`lvs -o lv_all,vg_all --reportformat=json`
`vgs -o vg_all,pv_all --reportformat=json`
Why do you want to expose the lv-info?
Why not? The LVs are the only thing I found for an OSD that contain some hint to
when it was created. Adding more general infos such as VG and LV for a specific
OSD can help users understand where the actual data is stored. And that without
digging even deeper into how things are handled internally and how it is mapped.
Cheers,
Aaron
_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
