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 D329A99EA7 for ; Thu, 4 May 2023 10:31:39 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id B06271B8BC for ; Thu, 4 May 2023 10:31:39 +0200 (CEST) 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 ; Thu, 4 May 2023 10:31:39 +0200 (CEST) Received: from proxmox-new.maurer-it.com (localhost.localdomain [127.0.0.1]) by proxmox-new.maurer-it.com (Proxmox) with ESMTP id A7B0A4728B; Thu, 4 May 2023 10:31:33 +0200 (CEST) Message-ID: <6ad543e0-38ad-4540-a39d-320009aa3f42@proxmox.com> Date: Thu, 4 May 2023 10:31:33 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird To: Thomas Lamprecht , Proxmox VE development discussion , Markus Frank References: <20230425102136.85334-1-m.frank@proxmox.com> <20230425102136.85334-4-m.frank@proxmox.com> <1ed81c96-4228-adea-c3ec-e82a29a9e59e@proxmox.com> Content-Language: en-US From: Dominik Csapak In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-SPAM-LEVEL: Spam detection results: 0 AWL -0.135 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 0.1 Meta: its spam POISEN_SPAM_PILL_1 0.1 random spam to be learned in bayes 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 T_SCC_BODY_TEXT_LINE -0.01 - Subject: Re: [pve-devel] [PATCH manager v4 3/6] added Config for Shared Filesystem Directories 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: Thu, 04 May 2023 08:31:39 -0000 On 5/4/23 10:13, Thomas Lamprecht wrote: > Am 03/05/2023 um 13:26 schrieb Dominik Csapak: >> just a short comment since this series overlaps a bit with my >> cluster resource mapping series (i plan on sending a v4 soon). >> >> i'd prefer to have the configuration endpoints for mapping bundled in a subdirectory >> so instead of /nodes//dirs/ i'd put it in /nodes//mapping/dirs/ >> (or /nodes//map/dirs ) >> >> @thomas, @fabian, any other input on that? >> > > huh? aren't mappings per definition cluster wide i.e. /cluster/resource-map/ > than then allows to add/update the mapping of a resource on a specific node? > A node specific path makes no sense to me, at max it would if adding/removing a mapping > is completely decoupled from adding/removing/updaing entries to it – but that seems > convoluted from an usage POV and easy to get out of sync with the actual mapping list. in markus series the mapping are only ever per node, so each node has it's own dir mapping in my series, the actual config was cluster-wide, but the api endpoint to configure them were sitting in the node path (e.g. /node//hardware-map/pci/*) the reason is that to check the validity of the mapping (at least for creating/updating) need to happen at the node itself anyway since only that node can check it (e.g. for pci devices, if it exists, the ids are correct etc.) we *could* put them into the cluster path api, but we'd need to send a node parameter along and forward it there anyway, so that wouldn't really make a difference for reading the mappings, that could be done there, but in my series in the gui at least, i have to make a call to each node to get the current state of the mapping (e.g. if the pci device is still there) if a mapping exists (globally) is not interesting most of the time, we only need to know if it exists at a specific node also, after seeing markus' patches, i also leaned more in the direction of splitting my global mapping config into a config per type+node (so node1/usb.conf, node1/pci.conf, etc.) since then i can omit my custom json/section config parser and use plain section configs. for the api calls it does not make a difference, since we only ever need to write from a specific node to that, and for the global state we can simply read all configs. (we then also can omit the global cluster lock for editing...) does that make sense?