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 7DD336AA76 for ; Thu, 17 Mar 2022 09:18:43 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 6D9512FBA9 for ; Thu, 17 Mar 2022 09:18:13 +0100 (CET) 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 D764D2FB9E for ; Thu, 17 Mar 2022 09:18:12 +0100 (CET) Received: from proxmox-new.maurer-it.com (localhost.localdomain [127.0.0.1]) by proxmox-new.maurer-it.com (Proxmox) with ESMTP id AAC4C46EA2 for ; Thu, 17 Mar 2022 09:18:12 +0100 (CET) Message-ID: <49888786-d3d2-c938-815a-613fdcec70e0@proxmox.com> Date: Thu, 17 Mar 2022 09:18:11 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.6.2 Content-Language: en-US To: Thomas Lamprecht , Proxmox VE development discussion , =?UTF-8?Q?Fabian_Gr=c3=bcnbichler?= References: <20211216121233.162288-1-f.ebner@proxmox.com> <20211216121233.162288-10-f.ebner@proxmox.com> <3c52b1a7-c53f-27de-f072-f8ddab32e102@proxmox.com> <3fc10567-ee00-5c5c-3879-131327d1a5ab@proxmox.com> <70e4e8d7-848d-0f1c-e03e-07247afbd0e2@proxmox.com> From: Fabian Ebner In-Reply-To: <70e4e8d7-848d-0f1c-e03e-07247afbd0e2@proxmox.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-SPAM-LEVEL: Spam detection results: 0 AWL 0.122 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 NICE_REPLY_A -0.001 Looks like a legit reply (A) SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record T_SCC_BODY_TEXT_LINE -0.01 - Subject: Re: [pve-devel] [PATCH guest-common 1/1] vzdump: schema: add 'notes' and 'protected' properties 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: Thu, 17 Mar 2022 08:18:43 -0000 Am 17.03.22 um 09:07 schrieb Thomas Lamprecht: > On 17.03.22 08:57, Fabian Ebner wrote: >> Am 16.03.22 um 19:25 schrieb Thomas Lamprecht: >>> >>> While extending one has a slight chance of changing an existing setup I find >>> this very unlikely in this specific case, as we had no such feature whatsoever >>> and it makes not sense in any practical example to use such special strings >>> for a backup comment. >> >> Yes, I'd simply document the list of currently valid variables, and that >> it might be extended in the future. >> > > k. > > a subset of the VM config could be possibly interesting too (e.g., ostype, first > line of description) but as the config is already in the backup it may not be worth > it - so maybe better to wait for the non-obvious variables for users to actually > requesting them. > Ok >>> >>> That said, if one can whip up another reason besides backward compat for >>> having a separate flag to turn this on/off then feel free to comment. >>> >>> I mean, for the backup jobs itself it could have some value to differ >>> between the comment about the job itself and a comment template for the >>> resulting backups. >> >> Yes, I think it'd be better to not mix the job's comment (which is part >> of the generic job properties) and the vzdump-specific notes{-template} >> which this patch (or rather a future version of it) will introduce. > > Agree. So, to summarize, vzdump does the interpreting for a plain, new `--notes` > CLI which it also prints (with variables already resolved) in the task log and > sets that also as note for the (created) backup. > > The job config would get a new notes-template config that allows to add such > a dynamically interpreted string to each backup created by this job by bassing > it as --notes to vzdump. That way we avoid vzdump having two different, clashing, > CLI options but keep it cleanly separated for the job definitions. I think it'd be better or even necessary for vzdump to do the variable expansion, because some things are not known when we start the job, for example guest name. It'd then be enough to add a notes-template option for vzdump, and have the job pass it along as-is with the rest of the vzdump-config.