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 DE45C84A2 for ; Mon, 25 Apr 2022 09:28:16 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id D30F04B0E for ; Mon, 25 Apr 2022 09:28:16 +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) server-digest SHA256) (No client certificate requested) by firstgate.proxmox.com (Proxmox) with ESMTPS id 55C024B01 for ; Mon, 25 Apr 2022 09:28:16 +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 2EA16428F4 for ; Mon, 25 Apr 2022 09:28:16 +0200 (CEST) Message-ID: <78d40de3-50fa-9f51-9542-b26f4eb7a6f9@proxmox.com> Date: Mon, 25 Apr 2022 09:28:15 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.8.0 Content-Language: en-US To: Thomas Lamprecht , Proxmox VE development discussion References: <20220421112659.74011-1-f.ebner@proxmox.com> <20220421112659.74011-12-f.ebner@proxmox.com> <29993f47-77f1-2701-e8d6-dd11a6b21a29@proxmox.com> From: Fabian Ebner In-Reply-To: <29993f47-77f1-2701-e8d6-dd11a6b21a29@proxmox.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-SPAM-LEVEL: Spam detection results: 0 AWL 1.015 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.857 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 v2 manager 1/3] ui: restore: disallow empty storage selection if it wouldn't work 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: Mon, 25 Apr 2022 07:28:16 -0000 Am 23.04.22 um 11:38 schrieb Thomas Lamprecht: > On 21.04.22 13:26, Fabian Ebner wrote: >> Namely, if there is a storage in the backup configuration that's not >> available on the current node. > > Better than the status quo, but in the long run all the "force all volumes to a single storage" > on restore and also migrate isn't ideal for the case where one or more storages do not exist on > the target node. An per-volume override would be nicer, but may require some gui adaptions to > present that in a sensible way with good UX. > In the UI, it could simply be part of the disk grid (proposed in patch manager 3/3), only showing up for drives selected from the backup? In the back-end for migration, we have a storage-storage map, but here we'd need a drive-storage map. It'd be possible to extend the 'storage' parameter for the create/restore API call to be such a map, but I wonder if going for a 'restore-drives' parameter being such a map (and replacing the proposed 'preserve-drives' parameter) would be better? The downside is, we'd have to choose between A) preserve disk and config B) preserve disk as unused for the drives that are not present in the backup. A) would be more convenient in the partial restore context, but B) is the current default. Thus we need to keep B) if 'restore-drives' is not specified at all for backwards-compatibility, but can choose A) if 'restore-drives' is specified. But doing so seems a little inconsistent regarding user expectation.