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 UTF8SMTPS id 001176112F for ; Wed, 2 Dec 2020 14:19:55 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with UTF8SMTP id E38461C1F5 for ; Wed, 2 Dec 2020 14:19:25 +0100 (CET) Received: from proxmox-new.maurer-it.com (proxmox-new.maurer-it.com [212.186.127.180]) (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 UTF8SMTPS id 7A8BB1C1E8 for ; Wed, 2 Dec 2020 14:19:25 +0100 (CET) Received: from proxmox-new.maurer-it.com (localhost.localdomain [127.0.0.1]) by proxmox-new.maurer-it.com (Proxmox) with UTF8SMTP id 3F705449DE; Wed, 2 Dec 2020 14:19:25 +0100 (CET) To: Thomas Lamprecht , Proxmox VE development discussion References: <20201202125631.19336-1-d.csapak@proxmox.com> <91926ff2-4ee0-e37b-3a93-26d06ef84c17@proxmox.com> From: Dominik Csapak Message-ID: <7f7e1ba3-1782-858c-6be6-90a2cf0916ee@proxmox.com> Date: Wed, 2 Dec 2020 14:19:23 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:84.0) Gecko/20100101 Thunderbird/84.0 MIME-Version: 1.0 In-Reply-To: <91926ff2-4ee0-e37b-3a93-26d06ef84c17@proxmox.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-SPAM-LEVEL: Spam detection results: 0 AWL 0.302 Adjusted score from AWL reputation of From: address KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment NICE_REPLY_A -0.001 Looks like a legit reply (A) RCVD_IN_DNSWL_MED -2.3 Sender listed at https://www.dnswl.org/, medium trust 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] fix #3182 #3183: change backup retention mask logic 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, 02 Dec 2020 13:19:56 -0000 On 12/2/20 2:11 PM, Thomas Lamprecht wrote: > On 02.12.20 13:56, Dominik Csapak wrote: >> instead of relying on the contentTypeField (which does not need to >> exists, e.g. for iscsi), explicitely write it into the panel/icon >> mapping and check that > > why not return it for iSCIS? > i don't understand what you mean? what should i return for iSCSI? do you mean i should add a field to the iscsi panel? (it has no content types to select, same as pbs/zfs over isci/etc.) >> >> better would be if we query the backend about storage capabilities, >> but such an api call does not exist yet, so this should be ok for now > > that's not true, the content type is exactly how the backend provides that, > that's why I used it. I'd like to avoid to further duplicating info all over > the place. > what i meant was the only 'real' way is to ask the backend (be it once or every time) what capabilities the storage has. now we are simply querying what we hardcoded for each storage in the frontend, my patch only adds a point where we save that specific info (again), which is not ideal i know