[pbs-devel] [PATCH proxmox{, -backup} v3 0/4] s3: extend config by provider-quirks and client options by feature list

[Thomas Lamprecht]

Am 05.08.25 um 07:58 schrieb Christian Ebner:
> On 8/4/25 10:17 PM, Thomas Lamprecht wrote:
>> Am 04.08.25 um 08:54 schrieb Christian Ebner:
>>> These patches extend the s3 client configuration by the additional
>>> `provider-quirks` enum, allowing to switch to provider specific implementation
>>> details. The provider specific quirks are then mapped to a list of features and
>>> limitations, added to the s3 client options.
>>>
>>> As first use-case, the `If-None-Match` header is not set during put object
>>> requests to Backblaze B2 or Infomaniak object stores, as these fail with an
>>> error with status code 501, therefore chunk uploads will fail.
>>
>> Why not expose the actual quirk (features) directly? Even if we'd like to
>> have specific providers a user can select, that part could be a frontend
>> only feature, and tbh. for starters I'd even skip that, maybe documenting
>> provider to quirks in the PBS wiki might be a good option for now.
>>
>> I'm just a bit wary of locking our backend in to those provider, as there
>> are quite a few of S3 provider, and not all might be here with us forever,
>> and having dozens of providers all mapping just to one or two actual
>> quirks each seems a bit overkill to me.
>> Sorry, I should have taken a closer check earlier to provider quicker
>> feedback.
> 
> The intention was to have it easy for the user to select the required features, therefore the mapping from provider to features.

Yes, I get that, and don't get me wrong, in general it _is_ a nice idea for
the UX. But IMO the backend should not have to care about this, especially
not a relatively low-level and generic S3 client crate. And the only benefit
I can see over a frontend implementation would be that we could adapt the
backend automatically to change in behavior of a provider. But such change is
IMO rather unlikely, as that would be a breaking change on their parts, and if
one provides a new API version we'd also start to version the providers in the
backend, and users might need to update PBS to get the updated provider
profile, instead of being able to enable any of the existing quirks. If we
need a new quirk in general one needs to update in any way, so for that
nothing changes – just to give some more rationale.

That's why I think that the user doesn't gets much value over this being a
front-end only profile once selected on endpoint creation – again, would not
do that now, but could see this as future UX improvement, depending on user
feedback.

> So I do agree, will move this over to only expose the features in the config and the single NoIfNoneMatchHeader in the UI for now (and maybe call them quirks, after all?)

It's a short name and definitively not wrong, so "quirks" works for me.