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 6BFFC91E0F for ; Sat, 11 Mar 2023 18:23:11 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 4A1192B8DD for ; Sat, 11 Mar 2023 18:23:11 +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 ; Sat, 11 Mar 2023 18:23:10 +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 662E741C68 for ; Sat, 11 Mar 2023 18:23:10 +0100 (CET) Message-ID: <2c8657ad-b1c5-c974-f279-57155a5273b0@proxmox.com> Date: Sat, 11 Mar 2023 18:23:09 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:111.0) Gecko/20100101 Thunderbird/111.0 Content-Language: de-AT, en-GB From: Thomas Lamprecht To: Proxmox VE development discussion , Dominik Csapak Reply-To: Proxmox VE development discussion References: <20230117114659.2397499-1-d.csapak@proxmox.com> <20230117114659.2397499-2-d.csapak@proxmox.com> <2eb7c57d-e5eb-75f0-337f-26c359762c95@proxmox.com> In-Reply-To: <2eb7c57d-e5eb-75f0-337f-26c359762c95@proxmox.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-SPAM-LEVEL: Spam detection results: 0 AWL -0.050 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 SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record Subject: [pve-devel] applied: [PATCH common v3 1/1] SectionConfig: add helper to delete keys from a section config entry 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: Sat, 11 Mar 2023 17:23:11 -0000 Am 08/03/2023 um 07:53 schrieb Thomas Lamprecht: > Am 17/01/2023 um 12:46 schrieb Dominik Csapak: >> this is a pattern we have very often, so we can implement that here and >> reuse it >> >> Signed-off-by: Dominik Csapak >> --- >> src/PVE/SectionConfig.pm | 15 +++++++++++++++ >> 1 file changed, 15 insertions(+) >> >> diff --git a/src/PVE/SectionConfig.pm b/src/PVE/SectionConfig.pm >> index 0a9f1cd..e354655 100644 >> --- a/src/PVE/SectionConfig.pm >> +++ b/src/PVE/SectionConfig.pm >> @@ -543,4 +543,19 @@ sub assert_if_modified { >> PVE::Tools::assert_if_modified($cfg->{digest}, $digest); >> } >> >> +sub delete_from_config { >> + my ($config, $option_schema, $new_options, $to_delete) = @_; >> + >> + for my $k ($to_delete->@*) { >> + my $d = $option_schema->{$k} || die "no such option '$k'\n"; >> + die "unable to delete required option '$k'\n" if !$d->{optional}; > > Should we use the (here already imported but not used) raise_param_exc ? Well, without any reply here I'll still apply it for now, as said signature change should not be required anyway. > As that would then also make the magic "mark-field-as-invalid" work if > used in API calls? > > FWIW, we could use a cumulative approach, e.g. something like like: > > my $errors = {}; > > for ... { > eval { > die "unable to delete fixed option\n" if $d->{fixed}; > ... > }; > if (my $err = $@) { > $errors->{$k} = $err; > } else { > delete ... > } > } > > raise_param_exc($errors) if scalar($errors->%*); I actually thought shortly that if, this would need to be: raise_param_exc({ delete => $joined_error_string }); As deletes normally come in via the 'delete' key, but from top of my head I don't know if we ever use our field invalidation magic for deletes..