From: Christian Ebner <c.ebner@proxmox.com>
To: Thomas Lamprecht <t.lamprecht@proxmox.com>,
Proxmox Backup Server development discussion
<pbs-devel@lists.proxmox.com>,
Hannes Laimer <h.laimer@proxmox.com>
Subject: Re: [pbs-devel] [PATCH] api: sync: list `all` instead of only `pull` synch jobs by default
Date: Wed, 5 Nov 2025 15:21:55 +0100 [thread overview]
Message-ID: <b71c2350-427e-4269-9102-009e3e102725@proxmox.com> (raw)
In-Reply-To: <a56dd5cc-ba2a-4844-a506-73081b4c6b59@proxmox.com>
On 11/5/25 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.
Yes, now all the sync jobs would be returned when no specific direction
was specified. Therefore this might cause issues for api consumers which
do not expect that.
But fallout from this is probably rather limited and easily fixed on
consumer side by also providing the flag to only list pull sync jobs
again if required.
> 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.
>
> [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
prev parent reply other threads:[~2025-11-05 14:21 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
2025-11-05 14:21 ` Christian Ebner [this message]
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=b71c2350-427e-4269-9102-009e3e102725@proxmox.com \
--to=c.ebner@proxmox.com \
--cc=h.laimer@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox