From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate001.proxmox.com (gate001.proxmox.com [IPv6:2a0f:8001:1:32::40]) by lore.proxmox.com (Postfix) with ESMTPS id 934B81FF0E5 for ; Wed, 15 Jul 2026 13:03:17 +0200 (CEST) Received: from gate001.proxmox.com (localhost.localdomain [127.0.0.1]) by gate001.proxmox.com (Proxmox) with ESMTP id 3E9382143E; Wed, 15 Jul 2026 13:03:16 +0200 (CEST) Message-ID: <3a2cf26c-4c86-4e2c-8cc3-b4fe004d6ee1@proxmox.com> Date: Wed, 15 Jul 2026 13:03:11 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Beta Subject: Re: [PATCH v2 storage 02/15] mapping: add base plugin To: Mira Limbeck , Dietmar Maurer , pve-devel@lists.proxmox.com References: <20260430173220.441001-1-m.limbeck@proxmox.com> <20260430173220.441001-3-m.limbeck@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: 1784113373893 X-SPAM-LEVEL: Spam detection results: 0 AWL 0.315 Adjusted score from AWL reputation of From: address DMARC_MISSING 0.1 Missing DMARC policy KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment (newer systems) RCVD_IN_DNSWL_LOW -0.7 Sender listed at https://www.dnswl.org/, low trust SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record Message-ID-Hash: SFNOIFZC6UOWYNIPS52ZG65OTLOIXYTQ X-Message-ID-Hash: SFNOIFZC6UOWYNIPS52ZG65OTLOIXYTQ 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 VE development discussion List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: Am 15.07.26 um 12:44 schrieb Mira Limbeck: > The inspiration to write it as a plugin on top of the current storage > plugins mostly came from the PCI and USB mapping plugins we already had. FWIW, the main two use case and rationale to have the mappings for them are: 1. Allow declaring with devices can be used for a VM to allow migration to other nodes. 2. Allow to pass out ACLs to such devices cleanly so that non-root users can use them too. If we want/need to support both points, for storage mappings too, then the resource mappings are a better fit. If that's not needed for all relevant use cases we want to care about, then a storage mapping is indeed simpler. Without thinking this through that deeply, the storage mapping case probably does not needs point 2, as storages themselves already have first-class support in the permission system. And just for the map itself - without the need for the mappings ACL infrastructure - they are rather overkill. So a per storage map is probably the better choice. btw. Wolfgang is checking out improving and leveraging the oneOf support of our schema to make the storage plugins use that with a mechanism to expose relevant (common) properties for external plugins for backward compat while making the schema basically work like it would then work in rust. While that might take a bit of time, a new property - like Dietmar's proposed "map" doesn't makes this really harder to do, so I'd not care to much for it.