From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [IPv6:2a01:7e0:0:424::9]) by lore.proxmox.com (Postfix) with ESMTPS id A7E7D1FF16B for ; Tue, 29 Jul 2025 13:17:36 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 61B5FEF6D; Tue, 29 Jul 2025 13:17:01 +0200 (CEST) From: Wolfgang Bumiller To: pve-devel@lists.proxmox.com Date: Tue, 29 Jul 2025 13:15:39 +0200 Message-ID: <20250729111557.136012-27-w.bumiller@proxmox.com> X-Mailer: git-send-email 2.47.2 In-Reply-To: <20250729111557.136012-1-w.bumiller@proxmox.com> References: <20250729111557.136012-1-w.bumiller@proxmox.com> MIME-Version: 1.0 X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1753787750537 X-SPAM-LEVEL: Spam detection results: 0 AWL 0.077 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 Subject: [pve-devel] [PATCH storage 26/26] update ApiChangeLog 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: , Reply-To: Proxmox VE development discussion Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: pve-devel-bounces@lists.proxmox.com Sender: "pve-devel" Signed-off-by: Wolfgang Bumiller --- ApiChangeLog | 53 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 53 insertions(+) diff --git a/ApiChangeLog b/ApiChangeLog index d80bfb3..ff85ee0 100644 --- a/ApiChangeLog +++ b/ApiChangeLog @@ -57,6 +57,59 @@ Future changes should be documented in here. which can override the default format. Must be implemented when the supported formats or default format depend on the storage configuration. +* There are now 2 new content types: "vm-vol" and "ct-vol", deprecating "images" and "rootdir" + types. + + These represent VM volumes and container volumes respectively. + + Usually, the legacy type "images" should *include* the new "vm-vol" type, and the legacy type + "rootdir" should *include* the new "ct-vol" type, but *not* the other way round. See the + description of `list_images` below. + +* The `get_subdir()` method may now be passed "vm-vol" or "ct-vol". + + Ideally these should map to directories separate from "images" and "rootdir", but as long as the + behavior of the other API methods works as intended, this is not strictly necessary. + +* Add `type` parameter to `list_images`. + + If this is not set, *all* images should be returned. + + - If `undef`, all volumes should be listed, legacy as well as vm-vol/ct-vol typed. + - For "images", this should return *all* untyped volumes *and* the ones of type "vm-vol". + - For "rootdir", this should return *all* untyped volumes *and* the ones of type "ct-vol". + - For "vm-vol", only volumes expicitly allocated with type "vm-vol" should be listed. + - For "ct-vol", only volumes expicitly allocated with type "ct-vol" should be listed. + +* Add `type` parameter to `alloc_image`. + + This parameter can be "vm-vol" or "ct-vol", and the storage plugin *should* store this alongside + the volumes (this can for instance be done via a naming convention). The type passed here is the + which should be returned in `list_images` and `parse_volname`. + + Legacy plugins inevitably ignore this and create volumes of legacy types. + + Note that "images" and "rootdir" will never be passed explicitly as these are considered + deprecated. + +* Add a `vtype` entry to `list_images` return type. + + For volumes which are known to be of type "vm-vol" or "ct-vol" the plugin *must* include a `vtype` + entry containing one of these values in the returned items. + For volumes without a type (eg. volumes created by previous versions of the plugin), the field + should not be set. + +* Add `type` parameter to `clone_image`. + + If the `type` is set, transitioning from a new vtype ("vm-vol" or "ct-vol") to the old "images" or + "rootdir" types must be rejected, while transitioning *to* the new vtypes should be allowed. + + The helper `PVE::Storage::Common::is_vtype_change_allowed(from, to)` can be used for this check. + +* Add `import_type` parameter to `volume_import`. + + The behavior should be similar to `rename_volume`. + ## Version 11: * Allow declaring storage features via plugin data -- 2.47.2 _______________________________________________ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel