From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by lists.proxmox.com (Postfix) with ESMTPS id C1964721F9 for ; Tue, 15 Jun 2021 10:17:51 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id B5D262B7B7 for ; Tue, 15 Jun 2021 10:17:51 +0200 (CEST) Received: from proxmox-new.maurer-it.com (proxmox-new.maurer-it.com [94.136.29.106]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by firstgate.proxmox.com (Proxmox) with ESMTPS id 3C3222B7A9 for ; Tue, 15 Jun 2021 10:17:51 +0200 (CEST) Received: from proxmox-new.maurer-it.com (localhost.localdomain [127.0.0.1]) by proxmox-new.maurer-it.com (Proxmox) with ESMTP id 0C20542ABA for ; Tue, 15 Jun 2021 10:17:51 +0200 (CEST) Message-ID: Date: Tue, 15 Jun 2021 10:17:45 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:90.0) Gecko/20100101 Thunderbird/90.0 Content-Language: en-US To: Proxmox VE development discussion , Fabian Ebner References: <20210416085127.17803-1-f.ebner@proxmox.com> From: Thomas Lamprecht In-Reply-To: <20210416085127.17803-1-f.ebner@proxmox.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-SPAM-LEVEL: Spam detection results: 0 AWL 0.931 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record URIBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [storage.pm] Subject: [pve-devel] applied: [PATCH/RFC storage] prune backups: activate storage X-BeenThere: pve-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox VE development discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jun 2021 08:17:51 -0000 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 > --- > > 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!