From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by lists.proxmox.com (Postfix) with ESMTPS id D104198821 for ; Mon, 13 Nov 2023 10:39:04 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id A90E8FF46 for ; Mon, 13 Nov 2023 10:38:34 +0100 (CET) Received: from proxmox-new.maurer-it.com (proxmox-new.maurer-it.com [94.136.29.106]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by firstgate.proxmox.com (Proxmox) with ESMTPS for ; Mon, 13 Nov 2023 10:38:33 +0100 (CET) Received: from proxmox-new.maurer-it.com (localhost.localdomain [127.0.0.1]) by proxmox-new.maurer-it.com (Proxmox) with ESMTP id C8C9A41A61; Mon, 13 Nov 2023 10:38:32 +0100 (CET) Date: Mon, 13 Nov 2023 10:38:26 +0100 From: Fabian =?iso-8859-1?q?Gr=FCnbichler?= To: Markus Ebner , Proxmox VE development discussion References: <20231108165239.22145-1-info@ebner-markus.de> <20231108165239.22145-2-info@ebner-markus.de> <1877948.CQOukoFCf9@pc.markus.lan> <29a09577-0c39-4191-970b-1910ccdd021a@proxmox.com> In-Reply-To: <29a09577-0c39-4191-970b-1910ccdd021a@proxmox.com> MIME-Version: 1.0 User-Agent: astroid/0.16.0 (https://github.com/astroidmail/astroid) Message-Id: <1699867751.gqn8ukz7bu.astroid@yuna.none> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-SPAM-LEVEL: Spam detection results: 0 AWL 0.067 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 SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record T_SCC_BODY_TEXT_LINE -0.01 - Subject: Re: [pve-devel] [PATCH qemu-server 1/1] fix #5033: api: Add target-filename option to move_disk reassign X-BeenThere: pve-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox VE development discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2023 09:39:04 -0000 On November 10, 2023 2:07 pm, Fiona Ebner wrote: > I'd rather go with your current approach than a new endpoint. Having > said that, another issue is that custom naming is not a first-class > feature currently, e.g. live-migration of a local disk or moving a disk > to a different storage or restoring from a backup will just throw away > the custom name. If we add more explicit support for custom names here, > then it's natural that users expect it to "just work" in all scenarios. >=20 > So I feel like it's a question of whether we want to better support > custom names in general. >=20 > There also is an open feature request to support comment fields for > disks (and other hardware items): > https://bugzilla.proxmox.com/show_bug.cgi?id=3D2672 and IMHO that would b= e > a cleaner solution than encoding custom information in the disk name itse= lf. >=20 > Opinions from other devs? there have been similar requests in the past, my preference would be: - expose "human readable" custom name more prominently in places where new volumes are created, not just on the CLI/API only storage layer - keep the name on operations that copy/move a volume if a conflict arises for the second part, we could simply bump the number-suffix until we find a free "slot", just like we do now for vm-XXX-disk-N. this would require a coordinated change through the storage plugins, although it would be possible to fall back to the old behaviour ("custom name" is lost) in PVE::Storage for (external) plugins that don't support this feature/API (yet). for doing a strict match/integration into external tooling, some sort of comment or attribute would be better, as that could be easily preserved on "move" type operations, and the external tooling would need to ensure it is set for "create" type operations, and updated for "copy" type operations if that is required (e.g., if it is supposed to be unique). one could argue that a comment is all that is needed for human readable labelling as well, but there are lots of people that *really* want vm-XXX-system-0.raw and vm-XXX-data-0.raw (or 'db', or ..) encoded directly in the volume (and thus file/..) name, since that is then also visible on the storage layer (in PVE, but also directly when doing disaster recovery/..), and I kind of see value in that as well.