From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <t.lamprecht@proxmox.com> 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 31D1C92A1A for <pve-devel@lists.proxmox.com>; Tue, 14 Feb 2023 11:07:03 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 102805E87 for <pve-devel@lists.proxmox.com>; Tue, 14 Feb 2023 11:07:03 +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 for <pve-devel@lists.proxmox.com>; Tue, 14 Feb 2023 11:07:02 +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 E957347125 for <pve-devel@lists.proxmox.com>; Tue, 14 Feb 2023 11:07:01 +0100 (CET) Message-ID: <31a05a3b-6132-93ca-837d-321d98c3548c@proxmox.com> Date: Tue, 14 Feb 2023 11:06:58 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:110.0) Gecko/20100101 Thunderbird/110.0 Content-Language: en-GB To: Proxmox VE development discussion <pve-devel@lists.proxmox.com>, Leo Nunner <l.nunner@proxmox.com> References: <20230209092705.29496-1-l.nunner@proxmox.com> <20230209092705.29496-4-l.nunner@proxmox.com> From: Thomas Lamprecht <t.lamprecht@proxmox.com> In-Reply-To: <20230209092705.29496-4-l.nunner@proxmox.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-SPAM-LEVEL: Spam detection results: 0 AWL 0.121 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.345 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 URIBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [proxmox.com] Subject: Re: [pve-devel] [PATCH docs] vzdump: document the new cluster-wide config file X-BeenThere: pve-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox VE development discussion <pve-devel.lists.proxmox.com> List-Unsubscribe: <https://lists.proxmox.com/cgi-bin/mailman/options/pve-devel>, <mailto:pve-devel-request@lists.proxmox.com?subject=unsubscribe> List-Archive: <http://lists.proxmox.com/pipermail/pve-devel/> List-Post: <mailto:pve-devel@lists.proxmox.com> List-Help: <mailto:pve-devel-request@lists.proxmox.com?subject=help> List-Subscribe: <https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel>, <mailto:pve-devel-request@lists.proxmox.com?subject=subscribe> X-List-Received-Date: Tue, 14 Feb 2023 10:07:03 -0000 On 09/02/2023 10:27, Leo Nunner wrote: > + change the wording from "Global configuration" to "Node-wide > configuration" > > Signed-off-by: Leo Nunner <l.nunner@proxmox.com> > --- > The wording was previously already changed by Fiona but hasn't been > merged yet: > > https://lists.proxmox.com/pipermail/pve-devel/2022-December/055123.html > > vzdump.adoc | 12 ++++++++---- > 1 file changed, 8 insertions(+), 4 deletions(-) > > diff --git a/vzdump.adoc b/vzdump.adoc > index ce46529..253f264 100644 > --- a/vzdump.adoc > +++ b/vzdump.adoc > @@ -473,13 +473,17 @@ entire process happens transparently from a user's point of view. > Configuration > ------------- > > -Global configuration is stored in `/etc/vzdump.conf`. The file uses a > -simple colon separated key/value format. Each line has the following > -format: > +Node-wide configuration is stored in `/etc/vzdump.conf`. A cluster-wide > +configuration can be found at `/etc/pve/vzdump.conf`. Note that this is merely > +a fallback, and that the node-wide configuration always has higher precedence. but node-specific configs do not take precedence over CLI? This is worded a bit confusing, maybe go for something more explicit as, i.e., something along the lines of: For each option the order of precendence is, Job or CLI option, if not defined then local node-specific config, if not defined there then datacenter wide config and if not defined there the default documented in the API schema. > +Options that are not set in the node-wide configuration will be taken from > +the cluster configuration, and, if not set there either, will take the default > +value. The files use a simple colon separated key/value format. Each line > +has the following format: > > OPTION: value > > -Blank lines in the file are ignored, and lines starting with a `#` > +Blank lines in the files are ignored, and lines starting with a `#` > character are treated as comments and are also ignored. Values from > this file are used as default, and can be overwritten on the command > line.