From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) by lore.proxmox.com (Postfix) with ESMTPS id A4CA91FF2AD for ; Thu, 4 Jul 2024 12:28:57 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 7C10D304ED; Thu, 4 Jul 2024 12:29:14 +0200 (CEST) Message-ID: <5b972ac1-42d1-4f53-b5c4-8423352f5e09@proxmox.com> Date: Thu, 4 Jul 2024 12:28:41 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird To: Thomas Lamprecht , Proxmox VE development discussion References: <20240610090415.13057-1-f.ebner@proxmox.com> <5e7e6f52-7ba0-42cd-a771-2261acd0dc36@proxmox.com> Content-Language: en-US From: Fiona Ebner In-Reply-To: <5e7e6f52-7ba0-42cd-a771-2261acd0dc36@proxmox.com> X-SPAM-LEVEL: Spam detection results: 0 AWL -0.312 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DMARC_MISSING 0.1 Missing DMARC policy KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment KAM_NUMSUBJECT 0.5 Subject ends in numbers excluding current years 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 storage] volume import: assume target API version is at least 9 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: , Reply-To: Proxmox VE development discussion Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: pve-devel-bounces@lists.proxmox.com Sender: "pve-devel" Am 04.07.24 um 11:52 schrieb Thomas Lamprecht: > Am 10/06/2024 um 11:04 schrieb Fiona Ebner: >> The storage API version has been bumped to at least 9 since >> libpve-storage = 7.0-4. If the source node is on Proxmox VE 8, where >> this change will come in, then the target node can be assumed to be >> running either Proxmox VE 8 or, during upgrade, the latest version of >> Proxmox VE 7.4, so it's safe to assume a storage API version of at >> least 9 in all cases. > > it's fine by me that this was applied, but can we somehow assert this > assumption with an early `die if $apiver < 7` ? (maybe don't die if the > apiver could not be queried/parsed, i.e. is undef, if there are > legitimate situations where this can happen). > Why version 7? We'd need to distinguish between there not being an apiinfo API call and other errors. The previous code did just continue if not being able to query (punting version to 1) and that lead to the very issue reported by Maximiliano. > While just one major release difference might be seen as enough, we still > have users that are doing some more funky stuff on upgrades of clusters, > so if it's somewhat easy to assert the assumption, doing so can > definitively only help to improve UX. Well, we'd have to put back in the apiinfo call for that. If using version 9 for the check instead of 7, the only thing it would do is die early when replicating back from an upgraded node to a node with libpve-storage < 7.0-4 For offline guest disk migration, the base_snapshot check doesn't matter so the only thing the check would catch is migrating back to a node with api version < 5 which means libpve-storage-perl < 6.1-6. I'd rather have the code cleaner than very slightly improve UX for users running ancient versions. _______________________________________________ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel