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.eb...@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! _______________________________________________ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
