From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate001.proxmox.com (gate001.proxmox.com [45.144.208.40]) by lore.proxmox.com (Postfix) with ESMTPS id C65C91FF0C4 for ; Sat, 22 Aug 2026 02:30:58 +0200 (CEST) Received: from gate001.proxmox.com (localhost.localdomain [127.0.0.1]) by gate001.proxmox.com (Proxmox) with ESMTP id 3B64E21586; Sat, 22 Aug 2026 02:30:58 +0200 (CEST) ARC-Seal: i=1; a=rsa-sha256; t=1787357739; cv=none; d=zohomail.com.au; s=zohoarc; b=onLCPh6459hsJSdKz2J6613xQHl5nf/lQ82tTXtYb5VhT7p2uwCKj35FbzsO+DuuF7xntp4fitJq13bOQeL6XzzRo/X54slpIyz078ngnLnX5hullxPnkrEJRC7/+bS3tXRMGB3KSI3WY9gbFt3rbdvCNghlrZTsb98XfqnMSNY= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com.au; s=zohoarc; t=1787357739; h=Content-Type:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:Reply-To:Reply-To:Subject:Subject:To:To:Message-Id:Cc; bh=GmgXrcKGVxN5napZFk81ex/cHoKFWrqWqRz6qMhXwRE=; b=OpXQAUq1yn9nQtRtBJ9RshjDSWrV4n8y6wN7f1eTo5EQQAfFTefdoX0UHmZw++GMsneh47l8MgQr1ODVup39glARwPCyeisFpgzdwFXJWurEMw0+xGSX1SeO0Ab9vxgnT2UXCspzz3sdjALSstrSFCW0TL1Z0fcKCRxZ33QFgyI= ARC-Authentication-Results: i=1; mx.zohomail.com.au; dkim=pass header.i=mooresolutions.co.nz; spf=pass smtp.mailfrom=thomas@mooresolutions.co.nz; dmarc=pass header.from= DKIM-Signature: a=rsa-sha256; b=IG2bX2RZWPQz3R67SD0XjzBfaccZqa7NGgPqEGIO8evILMDBkF2ogLVXEbef6DXz6eSjErI7pYe9jZHYnCSOXokMNJG+naOopUJ6vp+mVm2mezduvrRyZmEkrPQf3gxMWnHnKeRXUIGuNP2ZCedgoRIl7nmjYQ9FGcZ8vj8iztc=; c=relaxed/relaxed; s=zmail; d=mooresolutions.co.nz; v=1; bh=GmgXrcKGVxN5napZFk81ex/cHoKFWrqWqRz6qMhXwRE=; h=Content-Description:Content-ID:Content-Type:Content-Transfer-Encoding:Cc:Date:From:In-Reply-To:List-Subscribe:List-Post:List-Owner:List-Id:List-Archive:List-Help:List-Unsubscribe:MIME-Version:Message-ID:Resent-Sender:Resent-Cc:Resent-Date:Resent-To:Reply-To:Resent-Message-ID:Resent-From:Sender:Subject:To:Feedback-ID:Date:From:Message-Id:Reply-To:Subject:To:Cc; Date: Sat, 22 Aug 2026 12:15:38 +1200 From: thomas moore To: "pbs-devel" Message-Id: <1a026d2b773.4f0fd0cd237366.1462259800663760854@mooresolutions.co.nz> In-Reply-To: Subject: [RFC] add max-depth to the datastore snapshots API endpoint MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_847615_559236050.1787357738867" Importance: Medium User-Agent: Zoho Mail X-Mailer: Zoho Mail X-SPAM-LEVEL: Spam detection results: 0 DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain DMARC_PASS -0.1 DMARC pass policy HTML_MESSAGE 0.001 HTML included in message POISEN_SPAM_PILL_3 0.1 random spam to be learned in bayes RCVD_IN_DNSWL_NONE -0.0001 Sender listed at https://www.dnswl.org/, no trust SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record Message-ID-Hash: UGKFMXGWJ4AFOPENF7FBXMPVEIP2MUUR X-Message-ID-Hash: UGKFMXGWJ4AFOPENF7FBXMPVEIP2MUUR X-MailFrom: thomas@mooresolutions.co.nz X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; loop; banned-address; emergency; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.10 Precedence: list Reply-To: sales@mooresolutions.co.nz List-Id: Proxmox Backup Server development discussion List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: ------=_Part_847615_559236050.1787357738867 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi all This is a proposal for discussion, not a patch. The developer=C2=A0documentation asks that plans be discussed before starting work, so=C2=A0I'd like to check whether this would be acceptable before writing it. GET /api2/json/admin/datastore/{store}/snapshots returns only the=C2=A0snapshots in the requested namespace, so a client wanting a=C2=A0datastore-wide view has to call /admin/datastore/{store}/namespace=C2=A0first and then issue one snapshots request per namespace. I ran into=C2=A0this writing a third-party monitoring client. Tested against PBS 4.2: /admin/datastore/pbs/snapshots -> 485 snapshots (root only)=C2=A0 /admin/datastore/pbs/snapshots?ns=3Dtest -> 1 snapshot=C2=A0 /admin/datastore/pbs/snapshots?max-depth=3D7=C2=A0-> 400 parameter verification failed - 'max-depth': schema does=C2=A0not allow additional properties Proposal: accept an optional max-depth using the existing=C2=A0NS_MAX_DEPTH_SCHEMA, defaulting to 0 so behaviour is unchanged for=C2=A0current callers. This looks anticipated in the code. As of 5d95fc20e,=C2=A0src/api2/admin/datastore.rs lines 571, 575 and 583 each carry a=C2=A0"// FIXME: Recursion" on the group construction in=C2=A0list_snapshots_blocking, with a further one at 565 about filtering by=C2=A0owner before collecting. ListAccessibleBackupGroups already takes=C2=A0max_depth and applies the per-namespace privilege and owner checks=C2=A0during iteration, and get_snapshots_count uses it in roughly the shape=C2=A0list_snapshots would need. I'd send it as two patches: the refactor onto=C2=A0ListAccessibleBackupGroups with no behavioural change, then max-depth=C2=A0on top. I can test on a 4.2 instance including with a token holding=C2=A0DatastoreAudit on the root namespace only, to confirm namespaces the=C2=A0token cannot see stay absent from a recursive listing. Questions for the list 1. Is adding max-depth to the snapshots endpoint acceptable in principle? 2. Is ListAccessibleBackupGroups the right vehicle here, or is there a reason list_snapshots =09does not already use it? 3. Snapshot entries carry no namespace field, so a recursive listing is ambiguous unless the =09client tracks it per request. Adding one would mean a new field on SnapshotListItem, which =09is also decoded from remote instances in server/sync.rs and server/push.rs If you'd rather this were solved another way or not at all I'm happy=C2=A0to hear it before writing anything. Regards=C2=A0Thomas Moore ------=_Part_847615_559236050.1787357738867 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: 7bit

Hi all

This is a proposal for discussion, not a patch. The developer documentation asks that plans be discussed before starting work, so I'd like to check whether this would be acceptable before writing it.

GET /api2/json/admin/datastore/{store}/snapshots returns only the snapshots in the requested namespace, so a client wanting a datastore-wide view has to call /admin/datastore/{store}/namespace first and then issue one snapshots request per namespace. I ran into this writing a third-party monitoring client.

Tested against PBS 4.2:

/admin/datastore/pbs/snapshots -> 485 snapshots (root only) 

/admin/datastore/pbs/snapshots?ns=test -> 1 snapshot 

/admin/datastore/pbs/snapshots?max-depth=7 -> 400 parameter verification failed - 'max-depth': schema does not allow additional properties

Proposal: accept an optional max-depth using the existing NS_MAX_DEPTH_SCHEMA, defaulting to 0 so behaviour is unchanged for current callers.

This looks anticipated in the code. As of 5d95fc20e, src/api2/admin/datastore.rs lines 571, 575 and 583 each carry a "// FIXME: Recursion" on the group construction in list_snapshots_blocking, with a further one at 565 about filtering by owner before collecting. ListAccessibleBackupGroups already takes max_depth and applies the per-namespace privilege and owner checks during iteration, and get_snapshots_count uses it in roughly the shape list_snapshots would need.

I'd send it as two patches: the refactor onto ListAccessibleBackupGroups with no behavioural change, then max-depth on top. I can test on a 4.2 instance including with a token holding DatastoreAudit on the root namespace only, to confirm namespaces the token cannot see stay absent from a recursive listing.


Questions for the list

1. Is adding max-depth to the snapshots endpoint acceptable in principle?

2. Is ListAccessibleBackupGroups the right vehicle here, or is there a reason list_snapshots does not already use it?

3. Snapshot entries carry no namespace field, so a recursive listing is ambiguous unless the client tracks it per request. Adding one would mean a new field on SnapshotListItem, which is also decoded from remote instances in server/sync.rs and server/push.rs

If you'd rather this were solved another way or not at all I'm happy to hear it before writing anything.

Regards Thomas Moore



------=_Part_847615_559236050.1787357738867--