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 379F89686D for ; Wed, 25 Jan 2023 16:56:32 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 16C6219FF6 for ; Wed, 25 Jan 2023 16:56:32 +0100 (CET) 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 for ; Wed, 25 Jan 2023 16:56:27 +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 638EF460BC for ; Wed, 25 Jan 2023 16:56:27 +0100 (CET) Message-ID: <51411bea-d3a3-5352-e85f-5ac355e86e3f@proxmox.com> Date: Wed, 25 Jan 2023 16:56:26 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:110.0) Gecko/20100101 Thunderbird/110.0 To: Proxmox Backup Server development discussion , Christoph Heiss References: <20230125121902.404950-1-c.heiss@proxmox.com> <20230125121902.404950-2-c.heiss@proxmox.com> Content-Language: en-GB, de-AT From: Thomas Lamprecht In-Reply-To: <20230125121902.404950-2-c.heiss@proxmox.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-SPAM-LEVEL: Spam detection results: 0 AWL 0.527 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.148 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: [pbs-devel] [RFC PATCH v2 proxmox-backup 1/7] api2: Introduce server features discovery mechanism 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, 25 Jan 2023 15:56:32 -0000 Am 25/01/2023 um 13:18 schrieb Christoph Heiss: > This is vaguely based on the idea to introduce some sort of API > compatibility mechansim, to detect whether e.g. a new API parameter is > supported by the server or not. [0] > > Essentially, a new `features` field is added to the `/version` endpoint, > which is an array (of strings) of supported (backwards-incompatible) > features by the server. Clients can retrieve this and act accordingly. > Features are internally described as an enum, with kebab-case'd names > for external consumption through the API. > > Some inspriration was taken from how proxmox backup support in QEMU > works, using `query-proxmox-support` command. > > This is intended as a first proposal on how this mechanism could work. you could also just check the version? that's already there, no need for adding extra complexity. tbh, I'd be fine without any such check, as new *client* needing newer server is fine; one just does need to ensure that old clients still work with new server. If you want, you could catch the parameter exception in the PVE call site, either adding a hint about "new server required" or falling back there (albeit I'm not so liking that). After all immediate protection of backups is only relevant for manual trigerring that, not for the scheduled backup jobs, so it won't affect existing PVE jobs anyway.