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 1E2641FF15C for ; Wed, 22 Jan 2025 14:17:26 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 541881F186; Wed, 22 Jan 2025 14:17:22 +0100 (CET) Message-ID: Date: Wed, 22 Jan 2025 14:16:49 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird To: Fiona Ebner , Proxmox VE development discussion References: <20240916163839.236908-1-d.kral@proxmox.com> <20240916163839.236908-3-d.kral@proxmox.com> Content-Language: en-US From: Daniel Kral In-Reply-To: X-SPAM-LEVEL: Spam detection results: 0 AWL 0.012 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: Re: [pve-devel] [RFC qemu-server 2/9] cfg2cmd: improve error message for invalid volume storage content type 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: pve-devel-bounces@lists.proxmox.com Sender: "pve-devel" Thank you very much for taking a look over this! Sorry for taking such a long time for getting back to you on this, I'll rework this patch series for a v2 now. On 11/29/24 15:23, Fiona Ebner wrote: > Am 16.09.24 um 18:38 schrieb Daniel Kral: >> diff --git a/PVE/QemuServer/Helpers.pm b/PVE/QemuServer/Helpers.pm >> index 0afb6317..9d0f24aa 100644 >> --- a/PVE/QemuServer/Helpers.pm >> +++ b/PVE/QemuServer/Helpers.pm >> @@ -106,6 +106,51 @@ sub vm_running_locally { >> return; >> } >> >> +=head3 check_storage_content_type($storecfg, $storeid [, $content_type]) > > Usually, "assert_" rather than "check_" is used for such helpers that > die upon failing the check, so maybe "assert_content_type_supported" > > Nit: there is no blank line below the header when viewed with perldoc Hm, I'm sure it's possible but a quick glance over some other perldocs showed me that other perldocs don't seem to add a blank line below the function signature either (I looked at `AnyEvent::HTTP` and `Archive::Cpio` specifically, but they also seem to not follow the `head3` as we do). Do you have a reference that I can see how documentation should be formatted? > > I'd rather have the content type be non-optional. And actually, the > helper should live in the storage library, because it doesn't depend on > anything outside it. I agree, I'll make it required and move all other storage-related helpers to `PVE::Storage` too (which you pointed out) as it makes much more sense to have them there. > >> + >> +Checks whether the storage with the identifier C<$storeid>, that is defined in C<$storecfg>, >> +supports the content type C<$content_type>. If the C<$content_type> is undefined, it will default >> +to the value C<"images">. >> + >> +If the check fails, the subroutine will C with an error message containing the storage and >> +content type that is not supported. >> + >> +Returns C<1> if the check is successful. >> + >> +=cut >> + >> +sub check_storage_content_type : prototype($$;$) { >> + my ($storecfg, $storeid, $content_type) = @_; >> + >> + $content_type = "images" if !defined($content_type); >> + my $scfg = PVE::Storage::storage_config($storecfg, $storeid); >> + die "storage '$storeid' does not support content type '$content_type'\n" >> + if !$scfg->{content}->{$content_type}; >> + >> + return 1; >> +} >> + >> +=head3 check_volume_content_type($storecfg, $volid) > > assert_volume_content_type_supported > > should/could also live in the storage library ACK > >> + >> +Checks whether the volume with the identifier C<$volid>, that is defined in C<$storecfg>, supports >> +the content type, which is determined by L. >> + >> +If the check fails, the subroutine will C with an error message containing the storage and >> +content type that is not supported. >> + >> +Returns C<1> if the check is successful. >> + >> +=cut >> + >> +sub check_volume_content_type : prototype($$) { >> + my ($storecfg, $volid) = @_; >> + >> + my ($storeid) = PVE::Storage::parse_volume_id($volid); >> + my ($vtype) = PVE::Storage::parse_volname($storecfg, $volid); >> + >> + return check_storage_content_type($storecfg, $storeid, $vtype); >> +} >> + >> sub min_version { >> my ($verstr, $major, $minor, $pve) = @_; >> _______________________________________________ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel