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 14E536AA50 for ; Thu, 17 Mar 2022 09:08:21 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 014432F8CF for ; Thu, 17 Mar 2022 09:07:51 +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 537D02F8C4 for ; Thu, 17 Mar 2022 09:07:50 +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 2296041DAD for ; Thu, 17 Mar 2022 09:07:50 +0100 (CET) Message-ID: <70e4e8d7-848d-0f1c-e03e-07247afbd0e2@proxmox.com> Date: Thu, 17 Mar 2022 09:07:48 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:99.0) Gecko/20100101 Thunderbird/99.0 Content-Language: en-US To: Proxmox VE development discussion , Fabian Ebner , =?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> From: Thomas Lamprecht In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-SPAM-LEVEL: Spam detection results: 0 AWL 0.057 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:08:21 -0000 On 17.03.22 08:57, Fabian Ebner wrote: > Am 16.03.22 um 19:25 schrieb Thomas Lamprecht: >> On 16.03.22 12:04, Fabian Ebner wrote: >>> Am 16.12.21 um 13:12 schrieb Fabian Ebner: >>> >>> Fabian G.: >>> we could offer something like a simple template system that allows >>> substitution of certain variables (like name, or source node >>> hostname/clustername, ..). or just a boolean switch for setting VM/CT >>> $HOSTNAME from $CLUSTER/$NODENAME (or an enum, with >>> [job-comment,hostname,long,none] where long is that, and hostname is >>> just the guest hostname, and job-comment is the comment of the vzdump >>> job if one is set) >>> >>> Me: >>> The template variant would be the most flexible one and would avoid the >>> need for a second vzdump option besides --notes. Ideally, support for it >>> would be there from the beginning though, as otherwise it will stop >>> working for a user wanting to literally set $HOSTNAME when we add it ;) >>> The downside is that it doesn't match the volume-level --notes option, >>> but I don't think that should be a big deal. >>> >>> Fabian G.: >>> well it could just be called notes-template for vzdump to disambiguate? >> >> >> fwiw, I believe I commented that approach in the internal chat a while ago, >> but as its search functions are abysmal I don't find it anymore. >> >> IIRC, just extend what we have now and allow a fixed set of {VARS} (vmid, >> guest name, host name, job-id, ..?). > > I might be misunderstanding, but we don't have anything right now, > because this patch would be the one introducing the option? > yeah in this vzdump CLI context I was confusing, I talked more from the job POV. >> >> 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. >> >> 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.