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 1D7849F609 for ; Mon, 6 Nov 2023 11:38:30 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 0146214C4F for ; Mon, 6 Nov 2023 11:38:30 +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 11:38:28 +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 5334345C42; Mon, 6 Nov 2023 11:38:28 +0100 (CET) Message-ID: <91ba88cd-5adf-49db-ac1a-073dac6f0d44@proxmox.com> Date: Mon, 6 Nov 2023 11:38:27 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Beta Content-Language: en-US To: Fiona Ebner , 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> From: Dominik Csapak In-Reply-To: <7b552bd6-fbb2-45fc-84af-0498854c85c9@proxmox.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-SPAM-LEVEL: Spam detection results: 0 AWL 0.017 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. [realmsync.pm, proxmox.com] 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 10:38:30 -0000 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 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) > > E.g. > > root@pve8a1 ~ # pvesm set pbsenc --storage foobar this behaves like i mentioned above > root@pve8a1 ~ # pvesm add dir foo --storage bar --path /var/lib/vz i think this simply sets the 'storage' parameter twice, where the second one is just overwritten by the first (i.e. you can always give any parameter multiple times, but in this case the first one overwrites the later ones, in contrast to when the parameter is not positional) > root@pve8a1 ~ # grep bar /etc/pve/storage.cfg > 1 root@pve8a1 ~ # > > [0]: https://lists.proxmox.com/pipermail/pve-devel/2022-November/054714.html