From: Fiona Ebner <f.ebner@proxmox.com>
To: Proxmox VE development discussion <pve-devel@lists.proxmox.com>,
Daniel Kral <d.kral@proxmox.com>
Subject: Re: [pve-devel] [RFC qemu-server 2/9] cfg2cmd: improve error message for invalid volume storage content type
Date: Fri, 29 Nov 2024 15:23:35 +0100 [thread overview]
Message-ID: <afeea812-d462-4a56-a869-2ca592d64560@proxmox.com> (raw)
In-Reply-To: <20240916163839.236908-3-d.kral@proxmox.com>
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
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.
> +
> +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<die> 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
> +
> +Checks whether the volume with the identifier C<$volid>, that is defined in C<$storecfg>, supports
> +the content type, which is determined by L<PVE::Storage::parse_volname>.
> +
> +If the check fails, the subroutine will C<die> 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
next prev parent reply other threads:[~2024-11-29 14:23 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-16 16:38 [pve-devel] [RFC qemu-server 0/9] consistent checks for storage content types on volume disk allocation Daniel Kral
2024-09-16 16:38 ` [pve-devel] [RFC qemu-server 1/9] test: cfg2cmd: expect error for invalid volume's storage content type Daniel Kral
2024-11-29 14:23 ` Fiona Ebner
2024-09-16 16:38 ` [pve-devel] [RFC qemu-server 2/9] cfg2cmd: improve error message for invalid volume " Daniel Kral
2024-11-29 14:23 ` Fiona Ebner [this message]
2025-01-22 13:16 ` Daniel Kral
2025-01-22 14:31 ` Fiona Ebner
2024-09-16 16:38 ` [pve-devel] [RFC qemu-server 3/9] fix #5284: move_vm: add check if target storage supports vm images Daniel Kral
2024-11-29 14:23 ` Fiona Ebner
2025-01-22 13:18 ` Daniel Kral
2025-01-22 13:43 ` Daniel Kral
2025-01-22 14:35 ` Fiona Ebner
2024-09-16 16:38 ` [pve-devel] [RFC qemu-server 4/9] api: clone_vm: add check if " Daniel Kral
2024-11-29 14:23 ` Fiona Ebner
2025-01-22 13:18 ` Daniel Kral
2024-09-16 16:38 ` [pve-devel] [RFC qemu-server 5/9] api: create_vm: improve checks if storages for disks support " Daniel Kral
2024-09-16 16:38 ` [pve-devel] [RFC qemu-server 6/9] cloudinit: add check if storage for cloudinit disk supports " Daniel Kral
2024-09-16 16:38 ` [pve-devel] [RFC qemu-server 7/9] api: migrate_vm: improve check if target storages support " Daniel Kral
2024-11-29 14:23 ` Fiona Ebner
2025-01-22 13:19 ` Daniel Kral
2024-09-16 16:38 ` [pve-devel] [RFC qemu-server 8/9] api: importdisk: improve check if storage supports " Daniel Kral
2024-09-16 16:38 ` [pve-devel] [RFC qemu-server 9/9] restore_vm: improve checks " Daniel Kral
2024-11-29 14:23 ` Fiona Ebner
2025-01-22 13:21 ` Daniel Kral
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=afeea812-d462-4a56-a869-2ca592d64560@proxmox.com \
--to=f.ebner@proxmox.com \
--cc=d.kral@proxmox.com \
--cc=pve-devel@lists.proxmox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.