From: "Fabian Grünbichler" <f.gruenbichler@proxmox.com>
To: Christian Ebner <c.ebner@proxmox.com>,
Hannes Laimer <h.laimer@proxmox.com>,
Proxmox Backup Server development discussion
<pbs-devel@lists.proxmox.com>
Subject: Re: [pbs-devel] [PATCH] api: sync: list `all` instead of only `pull` synch jobs by default
Date: Wed, 05 Nov 2025 15:19:36 +0100 [thread overview]
Message-ID: <1762352327.2csa48r0oi.astroid@yuna.none> (raw)
In-Reply-To: <a56dd5cc-ba2a-4844-a506-73081b4c6b59@proxmox.com>
On November 5, 2025 3:14 pm, Thomas Lamprecht wrote:
> Am 04.11.25 um 09:58 schrieb Christian Ebner:
>> On 11/4/25 8:34 AM, Hannes Laimer wrote:
>>> There is no reason to still default to only listing pulling jobs.
>>
>> Well, this was overlooked for PBS 4.0, but I'm afraid the change needs to be postponed to PBS version 5.0, as this is a breaking API change.
>>
>
> This really just listing the specific job types IIUC?
>
> Returning new stuff is generally not a breaking change, here it was done
> to avoid confusing clients that are to old [0]. Albeit I'm now actually
> wondering which client can get confused? Third party integrations? As
> our CLI client has no support for managing sync jobs from a PBS, and the
> web UI might only have issues when a outdated version was loaded from the
> cache.
>
> Anyhow, even if I'm overlooking something now: while we want to have good
> forward compatibility support, especially for point releases from the same
> major release, this was introduced for PBS 3.3 about year ago. This means
> all officially supported clients and PBS support it, and as it's not related
> to backup protocol (write or restore), I really do not think we should let
> us hold back here, as in practice nothing will change w.r.t. compat compared
> to changing this already for 4.0 proper, and – again, if I do not miss
> something – this change really seems unproblematic in general.
IIRC the worry was that by listing all by default, a RMW cycle might
switch from push to pull if the client doing it doesn't understand that
there are multiple types now?
> [0]: commit 403ad1f6d ("api: admin: sync: add optional 'all' sync type for
> listing")
>
>
> _______________________________________________
> pbs-devel mailing list
> pbs-devel@lists.proxmox.com
> https://lists.proxmox.com/cgi-bin/mailman/listinfo/pbs-devel
>
_______________________________________________
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:[~2025-11-05 14:19 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-04 7:34 Hannes Laimer
2025-11-04 8:58 ` Christian Ebner
2025-11-05 14:14 ` Thomas Lamprecht
2025-11-05 14:19 ` Fabian Grünbichler [this message]
2025-11-05 14:21 ` 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=1762352327.2csa48r0oi.astroid@yuna.none \
--to=f.gruenbichler@proxmox.com \
--cc=c.ebner@proxmox.com \
--cc=h.laimer@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.