[pve-devel] [PATCH/RFC storage] prune backups: activate storage

[Fabian Ebner]

Any feedback for this?

Am 16.04.21 um 10:51 schrieb Fabian Ebner:
> which also checks whether the storage is even enabled. VZDump jobs already
> activate the storage, but more direct calls via API/CLI didn't do so yet.
> 
> Signed-off-by: Fabian Ebner <f.ebner at proxmox.com>
> ---
> 
> Or should the call rather be made in the API endpoints?
> 
> For functions like volume_resize, the callers in qemu-server/pve-container do
> the activation via activate_volumes, while for vdisk_* functions the activation
> happens directly in the functions.
> 
> The snapshot-related functions are also currently missing the activation/enabled
> check! Should the callers in guest-common do an activate_volumes call, or should
> we do an activate_storage in the functions themselves?
> 
> The first appraoch has the advantage of being more efficient (one activation
> call for the whole operation) and also more precise (if volume activation itself
> is actually needed), while the second one ensures that we do not forget to make
> the calls.
> 
>   PVE/Storage.pm | 2 ++
>   1 file changed, 2 insertions(+)
> 
> diff --git a/PVE/Storage.pm b/PVE/Storage.pm
> index 122c3e9..a856266 100755
> --- a/PVE/Storage.pm
> +++ b/PVE/Storage.pm
> @@ -1630,6 +1630,8 @@ sub prune_backups {
>   	$keep = PVE::JSONSchema::parse_property_string('prune-backups', $scfg->{'prune-backups'});
>       }
>   
> +    activate_storage($cfg, $storeid);
> +
>       my $plugin = PVE::Storage::Plugin->lookup($scfg->{type});
>       return $plugin->prune_backups($scfg, $storeid, $keep, $vmid, $type, $dryrun, $logfunc);
>   }
>