[pve-devel] [PATCH v2 storage 01/10] iscsi direct plugin: fix return value for path() method in non-array context

[Fiona Ebner]

Am 18.12.24 um 14:39 schrieb Fiona Ebner:
> Am 17.12.24 um 16:48 schrieb Fiona Ebner:
>> Signed-off-by: Fiona Ebner <f.ebner at proxmox.com>
>> ---
>>
>> New in v2.
>>
>>  src/PVE/Storage/ISCSIDirectPlugin.pm | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/src/PVE/Storage/ISCSIDirectPlugin.pm b/src/PVE/Storage/ISCSIDirectPlugin.pm
>> index eb329d4..6f02eee 100644
>> --- a/src/PVE/Storage/ISCSIDirectPlugin.pm
>> +++ b/src/PVE/Storage/ISCSIDirectPlugin.pm
>> @@ -100,7 +100,7 @@ sub path {
>>  
>>      my $path = "iscsi://$portal/$target/$lun";
>>  
>> -    return ($path, $vmid, $vtype);
>> +    return wantarray ? ($path, $vmid, $vtype) : $path;
>>  }
>>  
>>  sub create_base {
> 
> Actually, not sure if this is considered required by the plugin API (and
> thus whether to call it a "fix"). The call in Storage.pm is
> 
>>     my ($path, $owner, $vtype) = $plugin->path($scfg, $volname, $storeid, $snapname);
>>     return wantarray ? ($path, $owner, $vtype) : $path;
> 
> However, there are calls
> 
>> my $file = $class->path($scfg, $volname, $storeid)
> 
> in the (import/export calls) of the base implementation in Plugin.pm
> which can get inherited by other plugins. Either we require the
> wantarray detection in the API (technically also requires a APIAGE/VER
> bump) or we change these calls not to expect the detection.
> 

For v3 of the series, I'll just go with the latter. We can always do the
API change later on.

> IMHO, it seems nicer to have the detection, as it's very easy to end up
> with a broken call in scalar context.