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 BB61170AE6 for ; Wed, 15 Jun 2022 10:08:41 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id B21C327155 for ; Wed, 15 Jun 2022 10:08:11 +0200 (CEST) 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 id CE7392714A for ; Wed, 15 Jun 2022 10:08:10 +0200 (CEST) Received: from proxmox-new.maurer-it.com (localhost.localdomain [127.0.0.1]) by proxmox-new.maurer-it.com (Proxmox) with ESMTP id C3ADC43B58; Wed, 15 Jun 2022 10:08:09 +0200 (CEST) Message-ID: Date: Wed, 15 Jun 2022 10:08:08 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.0 To: Wolfgang Bumiller Cc: pbs-devel@lists.proxmox.com, Hannes Laimer References: <20220608085154.11271-1-h.laimer@proxmox.com> <20220615075842.uipxdoqc45eumcri@wobu-vie.proxmox.com> Content-Language: en-US From: Dominik Csapak In-Reply-To: <20220615075842.uipxdoqc45eumcri@wobu-vie.proxmox.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-SPAM-LEVEL: Spam detection results: 0 AWL 0.969 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 -1.732 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 T_SCC_BODY_TEXT_LINE -0.01 - URIBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [proxmox.com] Subject: Re: [pbs-devel] [PATCH proxmox-backup/proxmox-widget-toolkit v2 0/4] add partitions to disks/list endpoint X-BeenThere: pbs-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox Backup Server development discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2022 08:08:41 -0000 On 6/15/22 09:58, Wolfgang Bumiller wrote: > On Wed, Jun 08, 2022 at 08:51:50AM +0000, Hannes Laimer wrote: >> In order to work with the existing frontend component for displying the >> disklist, either >> * the partition data has to be return with the same struct a disk is >> returned. Which leads to the same struct being used for different >> things -> quite a few fields are always empty for partitions and a new >> 'type' field would be needed. Also the code structure in PBS has to be >> changed quite a bit. >> * the existing frontend has to be adjusted to handle data from PVE and >> PBS properly. >> >> I went with the second option because the adjustments nedded in the UI >> compenent were minimal and, IMHO, adjusting the API to fit the UI is the >> wrong direction. >> >> For the mount status to shown in the UI, the patch[1] sent to pve-devel for >> the 'mounted' column is needed. >> >> NOTE: The partition data will be needed in later patches for removable >> datastores. >> >> v1->v2: >> * use builder pattern for queries as suggested by Wolfgang >> * move mounted out of Enum and add filesystem string >> * add missing zfsreserve usage type >> * add 'mounted' column to disklist (separate patch[1]) >> >> >> [1] https://lists.proxmox.com/pipermail/pve-devel/2022-June/053211.html > > @Dominik: Not sure how to deal with the above patch linked, since AFAICT > right now the added column is (currently) pbs specific. > > Should the visibility of the mounted column be configurable? > Then again, we probably want to change PVE::Diskmanage & API to return > the mounted boolean as well? Currently it just slams a " (mounted)" text > onto the file system type, which is rather awkward (and does not happen > at all for eg. an ESP partition, which can definitely be mounted...). > > Though I suppose the series would still work without it, so I guess we > can apply this regardless? mhmm... i agree that we probably want to add that column for pve too... as an interim solution we could have a 'computed' field/renderer that takes either the 'mounted' column or tries to parse the '(mounted)' part of the 'used' one. once we have the mounted field in pve too, we can drop that and switch to that