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

[Thomas Lamprecht <t.lamprecht@proxmox.com>]

On 16.04.21 10:51, Fabian Ebner wrote:
> 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@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.

both can be OK as of now, this here seems a bit more convenient for the specific case,
we may want to stream line that a bit sometimes, but should be evaluated if there's
any gain from that (and be it only to have a nicer architecture to use), or at least
define some rough set of rules about when to do use what.

> 
> 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.

here the activate_volumes in guest-common seems slightly more sensible for me, mostly
due the single call for multiple volumes and IIRC we handle specific sets of volumes
more often that way, compared to the prune above, which does not yet has a specific
set of volumes to operate one, it always goes on the whole storage (so IMO fits slightly
better in the pve-storage part)

> 
>  PVE/Storage.pm | 2 ++
>  1 file changed, 2 insertions(+)
> 
>

applied, thanks!