From: Thomas Lamprecht <t.lamprecht@proxmox.com>
To: Proxmox Backup Server development discussion
<pbs-devel@lists.proxmox.com>,
Dominik Csapak <d.csapak@proxmox.com>
Subject: Re: [pbs-devel] [PATCH proxmox-backup] fix #5622: backup client: properly handle rate/burst parameters
Date: Wed, 7 Aug 2024 21:20:52 +0200 [thread overview]
Message-ID: <db743166-ea39-4287-9b96-90989e6c9fe2@proxmox.com> (raw)
In-Reply-To: <20240723100448.1571064-1-d.csapak@proxmox.com>
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.
_______________________________________________
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-07 19:20 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 [this message]
2024-08-08 6:51 ` Dominik Csapak
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=db743166-ea39-4287-9b96-90989e6c9fe2@proxmox.com \
--to=t.lamprecht@proxmox.com \
--cc=d.csapak@proxmox.com \
--cc=pbs-devel@lists.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.