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)) (No client certificate requested) by lists.proxmox.com (Postfix) with ESMTPS id 78CF9E616 for ; Fri, 9 Dec 2022 15:06:26 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 47DFE24C5A for ; Fri, 9 Dec 2022 15:05:56 +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)) (No client certificate requested) by firstgate.proxmox.com (Proxmox) with ESMTPS for ; Fri, 9 Dec 2022 15:05:55 +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 6105D4241C; Fri, 9 Dec 2022 15:05:55 +0100 (CET) Message-ID: <1f4d05f5-c1f7-f3ce-decc-42a1c03c933b@proxmox.com> Date: Fri, 9 Dec 2022 15:05:54 +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 Cc: pve-devel@lists.proxmox.com References: <8ade6295-3a6a-8e98-3310-a2085274c94d@proxmox.com> <20221206154755.2073326-2-a.lauterer@proxmox.com> <20221206154755.2073326-1-a.lauterer@proxmox.com> <1cfa70b807f858eea840bd040b9a83cd@antreich.com> From: Aaron Lauterer In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-SPAM-LEVEL: Spam detection results: 0 AWL 0.101 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.288 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: Fri, 09 Dec 2022 14:06:26 -0000 On 12/7/22 18:23, Alwin Antreich wrote: > December 7, 2022 2:22 PM, "Aaron Lauterer" wrote: > >> On 12/7/22 12:15, Alwin Antreich wrote: >> [...] >> >> '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. > > The lv_tags already shows the ID (ceph.osd_id=). And I just see that `ceph-volume lvm list > ` also exists, that is definitely faster then listing all OSDs. Ok I see now what you meant with the lv tags. I'll think about it. Adding the OSD ID to the ceph-volume call is definitely a good idea in case we stick with it. > >> 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. > > In my experience this data is only useful if you want to handle the OSD on the CLI. Hence my > question about the use-case. :) > > The metdata on the other hand displays all disks, sizes and more of an OSD. Then for example you > can display DB/WAL devices in the UI and how big the DB partition is. Did you look at the rest of the patches, or gave it a try on a test cluster? Quite a bit of the metadata for each device is shown. With additional infos of the underlying volume. I think it is nice, as it can make it a bit easier to know where to look for the correct volumes when CLI interaction on a deeper level is needed. If you see something that should be added as well, let me know :) And again, the creation time of the LV is the only thing I found where one can get an idea how old an OSD is. > > Cheers, > Alwin >