From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <t.lamprecht@proxmox.com> 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 DB569608DD for <pve-devel@lists.proxmox.com>; Wed, 2 Dec 2020 14:27:37 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id CC9D91C3D8 for <pve-devel@lists.proxmox.com>; Wed, 2 Dec 2020 14:27:07 +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 ESMTPS id 602851C3CE for <pve-devel@lists.proxmox.com>; Wed, 2 Dec 2020 14:27:07 +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 28A1A440F2 for <pve-devel@lists.proxmox.com>; Wed, 2 Dec 2020 14:27:07 +0100 (CET) To: Proxmox VE development discussion <pve-devel@lists.proxmox.com>, Dominik Csapak <d.csapak@proxmox.com> References: <20201202125631.19336-1-d.csapak@proxmox.com> <91926ff2-4ee0-e37b-3a93-26d06ef84c17@proxmox.com> <7f7e1ba3-1782-858c-6be6-90a2cf0916ee@proxmox.com> From: Thomas Lamprecht <t.lamprecht@proxmox.com> Message-ID: <c75f80e1-069a-75b6-01a8-74fba99ab890@proxmox.com> Date: Wed, 2 Dec 2020 14:27:06 +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: <7f7e1ba3-1782-858c-6be6-90a2cf0916ee@proxmox.com> Content-Type: text/plain; charset=UTF-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-SPAM-LEVEL: Spam detection results: 0 AWL -0.075 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 <pve-devel.lists.proxmox.com> List-Unsubscribe: <https://lists.proxmox.com/cgi-bin/mailman/options/pve-devel>, <mailto:pve-devel-request@lists.proxmox.com?subject=unsubscribe> List-Archive: <http://lists.proxmox.com/pipermail/pve-devel/> List-Post: <mailto:pve-devel@lists.proxmox.com> List-Help: <mailto:pve-devel-request@lists.proxmox.com?subject=help> List-Subscribe: <https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel>, <mailto:pve-devel-request@lists.proxmox.com?subject=subscribe> X-List-Received-Date: Wed, 02 Dec 2020 13:27:37 -0000 On 02.12.20 14:19, Dominik Csapak wrote: > 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? > >=20 > 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.) >=20 >=20 >>> >>> 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 al= l over >> the place. >> >=20 > what i meant was the only 'real' way is to ask the backend > (be it once or every time) what capabilities the storage has. >=20 > 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 >=20 hmm, true, we only have that info for existing storage - had wrongly the = content type split content view in mind... I'll rethink