Re: [PATCH pve-storage 7/7] api: add /nodes/<node>/storage/<storage>/identity route

[Christian Ebner <c.ebner@proxmox.com>]

On 4/21/26 3:51 PM, Thomas Lamprecht wrote:
> 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).

Yes, that was the main concern [0], especially with the client 
subcommand to get the server instance id being called `instance-id` 
client side, which IMO does not make sense and can be misleading.

> 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.

[0] 
https://lore.proxmox.com/pve-devel/ee0dcf35-41fe-4393-a86c-5bf1871633a4@proxmox.com/