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) server-digest SHA256) (No client certificate requested) by lists.proxmox.com (Postfix) with ESMTPS id 76CB49F5D7 for ; Mon, 6 Nov 2023 12:39:11 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 4D6D2156C3 for ; Mon, 6 Nov 2023 12:38:41 +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 ; Mon, 6 Nov 2023 12:38:40 +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 4FB0045FE6 for ; Mon, 6 Nov 2023 12:38:40 +0100 (CET) Message-ID: <995ce792-7814-4a29-a2a9-ee40e4ee6635@proxmox.com> Date: Mon, 6 Nov 2023 12:38:38 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: en-US To: Dominik Csapak , Proxmox VE development discussion References: <20231103115343.4133611-1-d.csapak@proxmox.com> <20231103115343.4133611-3-d.csapak@proxmox.com> <0ca79682-9c69-4fdf-a4ca-73dfb0adc396@proxmox.com> <66a5548b-f8ff-48bc-bccd-d71ed5f4769f@proxmox.com> <7b552bd6-fbb2-45fc-84af-0498854c85c9@proxmox.com> <91ba88cd-5adf-49db-ac1a-073dac6f0d44@proxmox.com> From: Fiona Ebner In-Reply-To: <91ba88cd-5adf-49db-ac1a-073dac6f0d44@proxmox.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-SPAM-LEVEL: Spam detection results: 0 AWL -0.080 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DMARC_MISSING 0.1 Missing DMARC policy 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 T_SCC_BODY_TEXT_LINE -0.01 - 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, jobbase.pm, realmsync.pm] Subject: Re: [pve-devel] [RFC PATCH guest-common 1/1] add profiles section config plugin 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: Mon, 06 Nov 2023 11:39:11 -0000 Am 06.11.23 um 11:38 schrieb Dominik Csapak: > On 11/6/23 11:12, Fiona Ebner wrote: >> Am 06.11.23 um 10:34 schrieb Dominik Csapak: >>> On 11/6/23 10:22, Fiona Ebner wrote: >>>> Am 03.11.23 um 12:53 schrieb Dominik Csapak: >>>>> +my $defaultData = { >>>>> +    propertyList => { >>>>> +    type => { description => 'Profile type.' }, >>>>> +    id => { >>>>> +        type => 'string', >>>>> +        description => "The ID of the profile.", >>>>> +        format => 'pve-configid', >>>>> +    }, >>>> >>>> The ID is usually not a property AFAIK. Doesn't this lead to >>>> duplication >>>> when writing the section config, i.e. >>>> >>>> type: >>>>      id >>>> >>>> ? Do we gain anything by having it be a property? >>> >>> mhm? the id has to be part of the properties, otherwise >>> the generated api with 'createSchema' etc. would not include it. >>> >>> (it isn't always named id, e.g. in the storage plugins >>> it's 'storage') >>> >> >> I was just reminded of [0], where it could lead to that situation. Would >> need to check if that patch still applies, because since then >> Jobs/RealmSync.pm has been added. >> >> But somebody needs to filter the 'storage' property, right? Isn't that >> property actually superfluous? > > well, yes and no, > > in a section config, we always have a global 'propertyList' > and a per type 'options' list (which only references the propertylist) > > when using the 'create/updateSchema' calls, *all* options from the > propertylist > will be included (incl. the type) so the id is always there Well, yes. If it was declared explicitly in the propertyList ;) I checked some other section configs and they all have an id (not always named id) property, so the question is what to do about the FIXME comment: https://git.proxmox.com/?p=pve-common.git;a=blob;f=src/PVE/Job/Registry.pm;h=32e02728d629dca67bc479a0c25d3ea3aae2858e;hb=HEAD#l18 Should we just remove the comment, because it's more consistent to other section configs with the ID rather than without? For the other one https://git.proxmox.com/?p=pve-common.git;a=blob;f=src/PVE/Job/Registry.pm;h=32e02728d629dca67bc479a0c25d3ea3aae2858e;hb=HEAD#l69 we can just drop the auto-injection, because neither VZDump/JobBase.pm nor Jobs/RealmSync.pm declare 'id' in their 'options', so the if condition is never true AFAICT. > > in the api calls, we then use this id, to modify the config > but it isn't actually contained in the 'options' of any type > and since we extract it from the parameters, it does not actually > land in the config part > > (ofc this is a bit error-prone, and forgetting to extract it would > lead to the situation you describe) > Okay, I see.