From: Daniel Kral <d.kral@proxmox.com>
To: Fiona Ebner <f.ebner@proxmox.com>,
Proxmox VE development discussion <pve-devel@lists.proxmox.com>
Subject: Re: [pve-devel] [RFC qemu-server 3/9] fix #5284: move_vm: add check if target storage supports vm images
Date: Wed, 22 Jan 2025 14:43:55 +0100 [thread overview]
Message-ID: <8c3a6896-601a-4c31-8732-b0be0c4a7530@proxmox.com> (raw)
In-Reply-To: <396f29b5-f9f3-47d7-bcf4-6e52c94c60c4@proxmox.com>
On 1/22/25 14:18, Daniel Kral wrote:
> On 11/29/24 15:23, Fiona Ebner wrote:
>> Am 16.09.24 um 18:38 schrieb Daniel Kral:
>>> +sub check_volume_alloc : prototype($$;$) {
>>
>> Again, "assert_" and "_permission"
>
> Hm, why did you choose permission here?
>
> There are no permission checks done here, would be a suffix like
> "_allowed" or "_available" also be fine for you?
>
>>
>> should/could also live in the storage library as it does not depend on
>> anything else
>
> ACK
>
>>
>>> + my ($storecfg, $storeid, $node) = @_;
>>> +
>>> + PVE::Storage::storage_check_enabled($storecfg, $storeid, $node);
>>> + check_storage_content_type($storecfg, $storeid);
>>> +
>>> + return 1;
>>> +}
>>> +
Also, I'll look whether we really need to decompose the "enabled" check
here. At first glance, it'd make sense to always assert whether the
storage is enabled since these assertions are mainly done to verify
early whether we can allocate images, so the storage must be enabled anyway.
I'll take a closer look and if it doesn't break anything that wouldn't
fail later on anyway, I'll move this into "assert_volume_alloc_*".
_______________________________________________
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:[~2025-01-22 13:44 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
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 [this message]
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=8c3a6896-601a-4c31-8732-b0be0c4a7530@proxmox.com \
--to=d.kral@proxmox.com \
--cc=f.ebner@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.