From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <c.ebner@proxmox.com> 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 7CCA5B37B5 for <pbs-devel@lists.proxmox.com>; Wed, 29 Nov 2023 10:13:55 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 57A322936 for <pbs-devel@lists.proxmox.com>; Wed, 29 Nov 2023 10:13:25 +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 <pbs-devel@lists.proxmox.com>; Wed, 29 Nov 2023 10:13:24 +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 991904228F for <pbs-devel@lists.proxmox.com>; Wed, 29 Nov 2023 10:13:24 +0100 (CET) Date: Wed, 29 Nov 2023 10:13:23 +0100 (CET) From: Christian Ebner <c.ebner@proxmox.com> To: Thomas Lamprecht <t.lamprecht@proxmox.com>, Proxmox Backup Server development discussion <pbs-devel@lists.proxmox.com> Message-ID: <1005038317.893.1701249203879@webmail.proxmox.com> In-Reply-To: <c6b4ce5b-cb56-46bd-aea6-b16e79e44ba7@proxmox.com> References: <20231128152519.34316-1-c.ebner@proxmox.com> <0070de9f-876b-4a31-8b7a-c9f08c341a24@proxmox.com> <665749042.845.1701246279052@webmail.proxmox.com> <c6b4ce5b-cb56-46bd-aea6-b16e79e44ba7@proxmox.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Priority: 3 Importance: Normal X-Mailer: Open-Xchange Mailer v7.10.6-Rev55 X-Originating-Client: open-xchange-appsuite X-SPAM-LEVEL: Spam detection results: 0 AWL 0.051 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: [pbs-devel] [PATCH proxmox-backup] api: add dedicated datastore disk schema X-BeenThere: pbs-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox Backup Server development discussion <pbs-devel.lists.proxmox.com> List-Unsubscribe: <https://lists.proxmox.com/cgi-bin/mailman/options/pbs-devel>, <mailto:pbs-devel-request@lists.proxmox.com?subject=unsubscribe> List-Archive: <http://lists.proxmox.com/pipermail/pbs-devel/> List-Post: <mailto:pbs-devel@lists.proxmox.com> List-Help: <mailto:pbs-devel-request@lists.proxmox.com?subject=help> List-Subscribe: <https://lists.proxmox.com/cgi-bin/mailman/listinfo/pbs-devel>, <mailto:pbs-devel-request@lists.proxmox.com?subject=subscribe> X-List-Received-Date: Wed, 29 Nov 2023 09:13:55 -0000 > On 29.11.2023 09:56 CET Thomas Lamprecht <t.lamprecht@proxmox.com> wrote: > > > Am 29/11/2023 um 09:24 schrieb Christian Ebner: > >> On 28.11.2023 18:49 CET Thomas Lamprecht <t.lamprecht@proxmox.com> wrote: > >> this is not really helping me, while that might be because its late, I also think > >> that this needs a different name, as what is a datastore-disk here actually? > > > > The intention was to distinguish between the datastore itself and the disk, on which the datastore might be created upon, as these are 2 independent entities. Most of the time they will be referred to by the same name, as e.g. created by `proxmox-backup-manager disk fs create foo --disk sdd --add-datastore true`. > > > > The base intention I get, and I think too that this could/should be > improved. > > > I choose to refer to this as `datastore disk` as that is what the API methods in src/api2/node/disks/directory.rs are called. > > > > Unfortunately, that does not really match up with ZFS, as there the name refers to the zpool. > > > > Why not STORAGE_NAME_SCHEMA then? As this is used as datastore name > is only for convenience and might not happen if one doesn't ticks the > "add as datastore" checkbox. > So having this naming hardwired to datastore or disk, while it isn't > necessarily related to either type, is IMO just not that ideal. Ah yes, referring to it as storage name is way better, didn't come to mind yesterday. This is generic enough to cover all cases. > > As description you could then use something like: > > "Name of the Storage. Will be also used for any datastore name, if part of an transaction." Maybe I will reduce this to a more compact: "Storage name. Implies the datastore name, if part of a transaction." Any opinions on that? > > (not really ideal as it's worded a bit overly generic, but just to convey > the base idea).