From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by lists.proxmox.com (Postfix) with ESMTPS id 89FF6E21E for ; Wed, 7 Dec 2022 14:22:30 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 667EFE6 for ; Wed, 7 Dec 2022 14:22:30 +0100 (CET) Received: from proxmox-new.maurer-it.com (proxmox-new.maurer-it.com [94.136.29.106]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by firstgate.proxmox.com (Proxmox) with ESMTPS for ; Wed, 7 Dec 2022 14:22:25 +0100 (CET) Received: from proxmox-new.maurer-it.com (localhost.localdomain [127.0.0.1]) by proxmox-new.maurer-it.com (Proxmox) with ESMTP id B92F54516C; Wed, 7 Dec 2022 14:22:25 +0100 (CET) Message-ID: <8ade6295-3a6a-8e98-3310-a2085274c94d@proxmox.com> Date: Wed, 7 Dec 2022 14:22:24 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.5.1 Content-Language: en-US To: Alwin Antreich , Proxmox VE development discussion References: <20221206154755.2073326-2-a.lauterer@proxmox.com> <20221206154755.2073326-1-a.lauterer@proxmox.com> <1cfa70b807f858eea840bd040b9a83cd@antreich.com> From: Aaron Lauterer In-Reply-To: <1cfa70b807f858eea840bd040b9a83cd@antreich.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-SPAM-LEVEL: Spam detection results: 0 AWL 0.088 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment NICE_REPLY_A -0.262 Looks like a legit reply (A) SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record Subject: Re: [pve-devel] [PATCH manager v4 1/3] api ceph osd: add OSD index, metadata and lv-info X-BeenThere: pve-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox VE development discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Dec 2022 13:22:30 -0000 On 12/7/22 12:15, Alwin Antreich wrote: > Hi, > > > December 6, 2022 4:47 PM, "Aaron Lauterer" 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