Re: [pve-devel] [PATCH pve-storage v2 2/5] introduce helpers for content type assertions of storages and volumes

[Daniel Kral <d.kral@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