public inbox for pbs-devel@lists.proxmox.com
 help / color / mirror / Atom feed
From: Dominik Csapak <d.csapak@proxmox.com>
To: Christian Ebner <c.ebner@proxmox.com>,
	Proxmox Backup Server development discussion
	<pbs-devel@lists.proxmox.com>
Subject: Re: [pbs-devel] [PATCH proxmox-backup 1/2] fix: ui: sync job: switch rate limit based on sync direction
Date: Mon, 17 Mar 2025 14:01:08 +0100	[thread overview]
Message-ID: <155d19a2-db5f-4c94-8149-7e0ccb01eb65@proxmox.com> (raw)
In-Reply-To: <7b209e27-1483-47ec-91a0-a23122b455fc@proxmox.com>

On 3/17/25 13:54, Christian Ebner wrote:
> On 3/17/25 13:36, Dominik Csapak wrote:
>> On 3/17/25 13:11, Christian Ebner wrote:
>>> On 3/17/25 12:56, Dominik Csapak wrote:
>>>> On 3/17/25 11:32, Christian Ebner wrote:
>>>>> On 3/17/25 11:07, Dominik Csapak wrote:
>>>>>> High level comment:
>>>>>>
>>>>>> I know it's preexisting, bu does it even make sense to have a 'rate- in' and 'rate-out' for sync
>>>>>> jobs? would it not make more sense to have a single 'rate' parameter and apply it to both
>>>>>> directions?
>>>>>
>>>>> You mean only as additional parameter for the api endpoint for sync job config creation and 
>>>>> update? Or as parameter for the sync job config itself?
>>>>>
>>>>> The former might be the better option, and one can check if both rate and rate-in/out were set 
>>>>> and abort with error in that case or abort with error if a rate-in was configured for a push or 
>>>>> rate-out for a pull?
>>>>>
>>>>
>>>> i had actually imagined 3 options for the sync job config
>>>> rate: limits both in/out
>>>> rate-in/out: precedence over rate, limits the respective direction
>>>>
>>>> and only expose the 'rate' option on the ui
>>>
>>> Okay, that makes sense, but the issue I see there is that per-existing rate limits are not shown 
>>> in the UI anymore, as the `rate` field is now used, while the config has the explicit `rate-in/ 
>>> out` set.
>>>
>>> So this would need some merging first, or am I missing something?
>>
>> no, you're right, but i think we have a few options:
>>
>> * contrary to what i suggested, don't prioritize rate-in/out, but only use it when 'rate' is not set
>> * delete rate-in/out when setting the rate via the gui
> 
> Both of these however still require some additional logic on the config values, which would be nice 
> if one could avoid. Having only `rate-in/out` at the config level makes more sense to me, avoiding 
> any need to conditionally merge or set values.
> 
>> * as you suggested in the other response, only keep rate-in and rate-out but expose both
>>    (although i can already see the confusion about what is 'in' and what is 'out' regarding sync 
>> direction)
> 
> This possible confusion could however be reduced by adding some more context to the field label (or 
> even symbols as for the sync direction on the create sync job buttons).
> E.g. `Rate limit in (pull contents)` and `Rate limit out (push contents)`.
> 
> Another option might be to make one or the other only visible in the UI for the corresponding sync 
> direction, or render the "less" useful rate limit in the advanced options only, depending on the 
> sync jobs type.

AFAIU this is basically what you sent (minus the deletion of the other option), right ?

> 
> But still wide open for other suggestions!

even another possibility is to simply set both from the ui?
as in we have a 'rate' field on the ui that sets both rate-in and rate-out?

the only question then is how to handle if the values are different on the backend...

The problem i have with the current way, is that we need to expose the user to a setting that
is unnecessary and confusing in most of the cases. I'd really like to make this not more
complicated as it already is. Thus my suggestion to reduce it to a single 'rate' parameter.


_______________________________________________
pbs-devel mailing list
pbs-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pbs-devel

  reply	other threads:[~2025-03-17 13:01 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-10 17:01 Christian Ebner
2025-03-10 17:01 ` [pbs-devel] [PATCH proxmox-backup 2/2] docs: mention how to set the push sync jobs rate limit Christian Ebner
2025-03-17 10:07 ` [pbs-devel] [PATCH proxmox-backup 1/2] fix: ui: sync job: switch rate limit based on sync direction Dominik Csapak
2025-03-17 10:32   ` Christian Ebner
2025-03-17 10:42     ` Christian Ebner
2025-03-17 11:56     ` Dominik Csapak
2025-03-17 12:11       ` Christian Ebner
2025-03-17 12:36         ` Dominik Csapak
2025-03-17 12:54           ` Christian Ebner
2025-03-17 13:01             ` Dominik Csapak [this message]
2025-03-17 13:17               ` Christian Ebner
2025-03-17 12:34       ` Christian Ebner

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=155d19a2-db5f-4c94-8149-7e0ccb01eb65@proxmox.com \
    --to=d.csapak@proxmox.com \
    --cc=c.ebner@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal