From: Dominik Csapak <d.csapak@proxmox.com>
To: Thomas Lamprecht <t.lamprecht@proxmox.com>,
Proxmox Backup Server development discussion
<pbs-devel@lists.proxmox.com>
Subject: Re: [pbs-devel] [PATCH proxmox-backup] fix #5622: backup client: properly handle rate/burst parameters
Date: Thu, 8 Aug 2024 08:51:49 +0200 [thread overview]
Message-ID: <455e08d5-1e28-4f64-b84c-cd216fda11af@proxmox.com> (raw)
In-Reply-To: <db743166-ea39-4287-9b96-90989e6c9fe2@proxmox.com>
On 8/7/24 21:20, Thomas Lamprecht wrote:
> On 23/07/2024 12:04, Dominik Csapak wrote:
>> the rate and burst parameters are integers, so the mapping from value
>> with `.as_str()` will always return `None` effectively never
>> applying any rate limit at all.
>>
>> To fix it, just map from u64 to HumanByte.
>>
>> Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
>> ---
>>
>> Alternatively, we could introduce a new string schema to parse into
>> HumanByte, if that's preferred. (Did not do it that way, because this
>> fix was way faster for me and is also OK in my opinion).
>
> I mean, tbh. it seems like this was the original intention, i.e. that one can
> also pass HumanByte here, which would be pretty convenient.
>
> FWIW, this was u64 back when added and there's a commit that changes this in a
> (buggy) way to the as_str, when HumanByte got introduced:
>
> 2d5287fb ("use RateLimitConfig for HttpClient and pull")
>
> Sadly the comment message of this and the previous ones are basically
> non-existent, but I faintly remember that Dietmar and I talked about this back
> then, and I'm pretty sure that my stance back then is as now: I find it odd
> that the API and config can have this written in HumanByte form but not on the
> CLI, where it'd be actually the most useful place; as the API is either
> accessed through web UI, where one can transform this from a human readable
> form to bytes or through a automation system, which normally have ways to
> allow X*1024 or the like calculations.
>
> So I'd rather go towards a HuamnByte based schema, albeit as the
> TRAFFIC_CONTROL_RATE_SCHEMA and TRAFFIC_CONTROL_BURST_SCHEMA are only used
> in the client CLI code anyway I'd actually drop them from pbs-api-types as
> they are obviously confusing (not used in the actual API) and either declare a
> ClientRateLimitConfig struct there (that is then flattened in the client backup
> schema definition) or just have something directly in the client code.
>
Sure, make sense, I'll see that I take the time to do that, thanks for the input!
_______________________________________________
pbs-devel mailing list
pbs-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pbs-devel
next prev parent reply other threads:[~2024-08-08 6:52 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-23 10:04 Dominik Csapak
2024-07-23 12:48 ` Christian Ebner
2024-07-23 12:51 ` Christian Ebner
2024-08-01 12:44 ` Christian Ebner
2024-08-01 13:14 ` Christian Ebner
2024-08-07 19:20 ` Thomas Lamprecht
2024-08-08 6:51 ` Dominik Csapak [this message]
2024-08-09 8:22 ` Dominik Csapak
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=455e08d5-1e28-4f64-b84c-cd216fda11af@proxmox.com \
--to=d.csapak@proxmox.com \
--cc=pbs-devel@lists.proxmox.com \
--cc=t.lamprecht@proxmox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal