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) server-digest SHA256)
 (No client certificate requested)
 by lists.proxmox.com (Postfix) with ESMTPS id 379F89686D
 for <pbs-devel@lists.proxmox.com>; 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 <pbs-devel@lists.proxmox.com>; 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 <pbs-devel@lists.proxmox.com>; 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 <pbs-devel@lists.proxmox.com>; 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
 <pbs-devel@lists.proxmox.com>, Christoph Heiss <c.heiss@proxmox.com>
References: <20230125121902.404950-1-c.heiss@proxmox.com>
 <20230125121902.404950-2-c.heiss@proxmox.com>
Content-Language: en-GB, de-AT
From: Thomas Lamprecht <t.lamprecht@proxmox.com>
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
 <pbs-devel.lists.proxmox.com>
List-Unsubscribe: <https://lists.proxmox.com/cgi-bin/mailman/options/pbs-devel>, 
 <mailto:pbs-devel-request@lists.proxmox.com?subject=unsubscribe>
List-Archive: <http://lists.proxmox.com/pipermail/pbs-devel/>
List-Post: <mailto:pbs-devel@lists.proxmox.com>
List-Help: <mailto:pbs-devel-request@lists.proxmox.com?subject=help>
List-Subscribe: <https://lists.proxmox.com/cgi-bin/mailman/listinfo/pbs-devel>, 
 <mailto:pbs-devel-request@lists.proxmox.com?subject=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.