[pbs-devel] [PATCH v6 proxmox-backup 12/29] api/api-types: refactor api endpoint version, add api types

Thomas Lamprecht t.lamprecht at proxmox.com
Thu Nov 21 17:01:05 CET 2024


Am 21.11.24 um 10:58 schrieb Christian Ebner:
> On 11/21/24 10:23, Thomas Lamprecht wrote:
> Well, that is something I did not consider at all! So with that 
> viewpoint, adding this to PBS specifically is surely not the best way. 
> As discussed with Fabain off list, version based matching will be the 
> best way forward here, and dropping the incompatibility check once EOL 
> is reached.

If we add such a thing that you proposed we should definitively get the
story somewhat straight w.r.t. how we want to handle this for all projects,
and define when to define a feature and when not, with some extra care on
the interfaces, as those are relatively set in stone.

>>
>> Something tangentially related:
>>
>> In general, it might be also worth thinking about how the protection flag can
>> be better synced – FWICT it's now set if the source has it set and then never
>> will get unset manually anymore? Remembering the source of the flag (i.e.,
>> sync from remote vs local api) could be an option to differentiate here when
>> it's OK to clear on sync transiently again (probably guarded as option in the
>> job). But here I'm a bit more distanced from the matter than you are, I'll need
>> to think a bit more about this all.
>>
>> For now maybe order the whole API feature thing towards the end of the series
>> and we can still commit all earlier patches already and decide on this a
>> (short) time later.
> 
> Not sure if I correctly interpreted you rational here.
> As Fabian mentioned, the additional parameter only included in the api 
> calls is not to handle how we sync the flag, but rather how to act in 
> case the sync jobs should prune vanished snapshots/groups from the remote.


Yeah, ignore that part; I forgot that we do not sync the protected flag
at all, sorry for the noise.




More information about the pbs-devel mailing list