From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [IPv6:2a01:7e0:0:424::9]) by lore.proxmox.com (Postfix) with ESMTPS id EBA351FF142 for ; Tue, 21 Apr 2026 15:52:53 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id CAB672529D; Tue, 21 Apr 2026 15:52:53 +0200 (CEST) Message-ID: <85e5c377-ab04-407a-9670-7552591791f1@proxmox.com> Date: Tue, 21 Apr 2026 15:52:48 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Beta Subject: Re: [PATCH pve-storage 7/7] api: add /nodes//storage//identity route To: Lukas Wagner , Fiona Ebner , pbs-devel@lists.proxmox.com, pve-devel@lists.proxmox.com References: <20260415115817.348947-1-l.wagner@proxmox.com> <20260415115817.348947-8-l.wagner@proxmox.com> <262d3355-b8ec-470c-8fed-32a7b151fee4@proxmox.com> <231a34ce-06cb-40b7-b0d8-6238e368e60c@proxmox.com> Content-Language: en-US From: Thomas Lamprecht In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1776779483600 X-SPAM-LEVEL: Spam detection results: 0 AWL -0.048 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DMARC_MISSING 0.1 Missing DMARC policy KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment POISEN_SPAM_PILL_3 0.1 random spam to be learned in bayes SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record URIBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [proxmox.com] Message-ID-Hash: 43CEDS5F2WMOGC4Y4SBYISUUDX64NUYQ X-Message-ID-Hash: 43CEDS5F2WMOGC4Y4SBYISUUDX64NUYQ X-MailFrom: t.lamprecht@proxmox.com 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 List-Id: Proxmox Backup Server development discussion List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: Am 21.04.26 um 15:05 schrieb Lukas Wagner: > On Tue Apr 21, 2026 at 2:35 PM CEST, Thomas Lamprecht wrote: >> Am 17.04.26 um 11:10 schrieb Lukas Wagner: >>> On Fri Apr 17, 2026 at 10:54 AM CEST, Fiona Ebner wrote: >>>> Am 15.04.26 um 1:57 PM schrieb Lukas Wagner: >>>>> @@ -308,6 +308,7 @@ __PACKAGE__->register_method({ >>>>> { subdir => 'download-url' }, >>>>> { subdir => 'file-restore' }, >>>>> { subdir => 'import-metadata' }, >>>>> + { subdir => 'identity' }, >>>> >>>> Just bike-shedding, but I'm wondering if 'identifier' would be slightly >>>> more natural? >>> >>> I can change it if you prefer, but I think I prefer 'identity', if I'm >>> honest. >> Why not "instance-id"? it's used widely in this series and is IMO quite >> descriptive. > > It was 'instance-id' in the RFC, but in the patch notes I mentioned that > a more generic term could maybe be useful in case we want need to reuse the > concept of a identity for other storages as well, to which Chris agreed. IMO identity and instance-id are both basically just as generic, or at least one isn't so much more specific that the difference actually relays to the user something. > After some brief discussion with Chris I went for 'identity' [1]. > > In the PBS-client part of these patches, Chris mentioned that > 'instance-id' alone could be misleading [2, 3], which is why I went with > the names that I used in this series. Well, FWICT Chris didn't really mentioned that what the ID of the "instance-id" part actually pointed at could be potentially misleading, which I can somewhat relate to as concern, some might indeed expect this ID/identity to pop up in logs or configs as "for this client instance/id). But for one that's IMO not specific to using "instance-id", that's often an issue when talking about server properties in client, and IMO using "identity" doesn't really fixes this either, rather one would need to specify that it's the (instance) ID of the server, e.g., by using "server-instance-id" or "server-identity" - again, both are fine in general, but there's really no difference for the presented arguments here, important is to add the actual subject of the id/identity/identifier/... over using some synonym or. > If you prefer the more specific 'instance-id', I can of course change it > back to that. Would you then also propose changing the terms used in > PBS? There we now the 'server-identity' sub-commands for manager and > client and the '/nodes/.../server-identity' routes, which *return* the > `pbs-instance-id` field in the response. IMO it can be more than fine to e.g. use "xyz" in the server and "server-xyz" for that thing in the client, albeit not a must and can have a slight headache to hold up that difference when using shared (struct) types. That said, I like the ring of instance-id and it somewhat fits in naming with the existing machine-id, but that really isn't a deciding factor on it's own. My main point is that just omitting "instance" and spelling out ID as identity IMO doesn't solves the - IMO not big but definitively real - concern that Chris pointed out, for that IMO "server-identity", "server-id", "server-instance-id" would be all much better, as they actually relay where the ID comes from, i.e., what it actually identifies. > > [1] https://lore.proxmox.com/pve-devel/98f893be-871c-4a46-9b06-3ee17978131d@proxmox.com/ > > [2] https://lore.proxmox.com/pve-devel/9a4d051a-58a5-445f-a127-c11706d93194@proxmox.com/ > [3] https://lore.proxmox.com/pve-devel/ee0dcf35-41fe-4393-a86c-5bf1871633a4@proxmox.com/ Thanks for those references in any case.