From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <pve-devel-bounces@lists.proxmox.com> Received: from firstgate.proxmox.com (firstgate.proxmox.com [IPv6:2a01:7e0:0:424::9]) by lore.proxmox.com (Postfix) with ESMTPS id 4910F1FF16B for <inbox@lore.proxmox.com>; Thu, 20 Feb 2025 10:14:52 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 43A28C429; Thu, 20 Feb 2025 10:14:45 +0100 (CET) Message-ID: <13dd23d2-5a04-4ce2-b047-a93247ae0300@proxmox.com> Date: Thu, 20 Feb 2025 10:14:11 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird To: Fiona Ebner <f.ebner@proxmox.com>, Proxmox VE development discussion <pve-devel@lists.proxmox.com> References: <20250211160825.254167-1-d.kral@proxmox.com> <20250211160825.254167-3-d.kral@proxmox.com> <da714d0b-c93b-4734-b91a-b6783bf1af49@proxmox.com> Content-Language: en-US From: Daniel Kral <d.kral@proxmox.com> In-Reply-To: <da714d0b-c93b-4734-b91a-b6783bf1af49@proxmox.com> X-SPAM-LEVEL: Spam detection results: 0 AWL 0.008 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 RCVD_IN_VALIDITY_CERTIFIED_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. RCVD_IN_VALIDITY_RPBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. RCVD_IN_VALIDITY_SAFE_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record Subject: Re: [pve-devel] [PATCH pve-storage v2 2/5] introduce helpers for content type assertions of storages and volumes X-BeenThere: pve-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox VE development discussion <pve-devel.lists.proxmox.com> List-Unsubscribe: <https://lists.proxmox.com/cgi-bin/mailman/options/pve-devel>, <mailto:pve-devel-request@lists.proxmox.com?subject=unsubscribe> List-Archive: <http://lists.proxmox.com/pipermail/pve-devel/> List-Post: <mailto:pve-devel@lists.proxmox.com> List-Help: <mailto:pve-devel-request@lists.proxmox.com?subject=help> List-Subscribe: <https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel>, <mailto:pve-devel-request@lists.proxmox.com?subject=subscribe> Reply-To: Proxmox VE development discussion <pve-devel@lists.proxmox.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: pve-devel-bounces@lists.proxmox.com Sender: "pve-devel" <pve-devel-bounces@lists.proxmox.com> On 2/19/25 15:54, Fiona Ebner wrote: > Am 11.02.25 um 17:07 schrieb Daniel Kral: >> Add subroutines for asserting the content types of storages and volumes >> to reduce code duplication, e.g. when implementing preconditions in an >> API handler before calling vdisk_alloc. >> >> Signed-off-by: Daniel Kral <d.kral@proxmox.com> >> --- >> changes since v1: >> - moved from qemu-server to pve-storage >> - add missing $node parameter to helpers >> - adapt and fix wrong docs (copy paste error) >> - remove `alloc_volume_disk` and `check_{volume,storage}_alloc` >> >> src/PVE/Storage.pm | 40 ++++++++++++++++++++++++++++++++++++++++ >> 1 file changed, 40 insertions(+) >> >> diff --git a/src/PVE/Storage.pm b/src/PVE/Storage.pm >> index 3b4f041..ca69cd6 100755 >> --- a/src/PVE/Storage.pm >> +++ b/src/PVE/Storage.pm >> @@ -529,6 +529,46 @@ sub parse_volume_id { >> return PVE::Storage::Plugin::parse_volume_id($volid, $noerr); >> } >> >> +=head3 assert_content_type_supported($cfg, $storeid, $content_type [, $node]) >> + >> +Asserts whether the storage with the identifier C<$storeid>, which is defined in C<$cfg>, supports >> +the content type C<$content_type>. >> + >> +If C<$node> is set, the assertion is made for the specified C<$node>, else for the current node. >> + >> +If the check fails, the subroutine will C<die> with an error message for either the storage being >> +unavailable or the storage not supporting the specified content type. >> + > > I'd rather group the functions with their respective doc. I.e. > doc+function,doc+function instead of doc+doc,function+function. Will do so in a v3! > >> +=head3 assert_volume_type_supported($cfg, $volid [, $node]) >> + >> +Asserts whether the volume with the identifier C<$volid>, which is on a storage defined in C<$cfg>, >> +supports the volume's content type determined by L<parse_volname>. >> + >> +If C<$node> is set, the assertion is made for the specified C<$node>, else for the current node. >> + >> +If the check fails, the subroutine will C<die> with an error message for either the storage being >> +unavailable or the storage not supporting the volume's content type. >> + >> +=cut >> + >> +sub assert_content_type_supported : prototype($$$;$) { >> + my ($cfg, $storeid, $content_type, $node) = @_; >> + >> + my $scfg = storage_config($cfg, $storeid, $node); > > The storage_config() function does not have a $node parameter, but a > $noerr parameter. I guess you want to use storage_check_enabled() since > the documentation talks about "storage being unavailable"? Uff sorry, that's right that was an oversight and doesn't make sense... Yes you're correct, I had the `storage_check_enabled` here before, but replaced it in the end but forgot to remove the parameter. There are AFAIK 5 instances where I used this helper where there wasn't a `storage_check_enabled` before and I was worried about breaking any existing checks at these locations and another helper (with just an added `storage_check_enabled`) felt like bloat. I checked the locations again where there wasn't a `storage_check_enabled` before: - qemu-server patch #9 (in `config_to_command`), - qemu-server patch #11 (in `check_storage_access`), - qemu-server patch #13 (in `parse_backup_hints`), - container patch #10 (in `update_pct_config`), and - container patch #11 (in `__mountpoint_mount`). If we could use the `storage_check_enabled` in all of those, I'd move the `storage_check_enabled` in the helper method and add to each patch message where there was a `storage_check_enabled` before with "No functional changes intended" and those where it wasn't with a reason why it makes sense to add one now. If I didn't miss anything: - qemu-server #9 - `config_to_command` obviously fails at another location if the storage is not currently enabled anyway - qemu-server #11 - `check_storage_access` is called in the create_vm and update_vm API handler... where it checks whether any new disk can be put on the storage (also fails when the storage is not enabled) - qemu-server #13 - `parse_backup_hints` is used in `restore_vma_archive` and `restore_proxmox_backup_archive` to parse and check whether the devices can be allocated (with `$restore_allocate_devices` afterwards) - container #10 - `update_pct_config` asserts whether new or changed mountpoints can be allocated... and fails if the storage is not enabled - container #11 - `__mountpoint_mount` is used in more places, but all look to need the volume on the storage immediately afterwards anyway (`snapshot`, `archive`, resize_vm API handler, `copy_volume`)... and I guess it would fail in any of those with `PVE::Storage::activate_volumes` calling `activate_storage` before the helper anyway So if I didn't miss anything, I'd do this in a v3. _______________________________________________ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel