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 D4D3D8A890 for ; Thu, 20 Oct 2022 16:20:05 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id ADAA118CED for ; Thu, 20 Oct 2022 16:20:05 +0200 (CEST) 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 ; Thu, 20 Oct 2022 16:20:02 +0200 (CEST) Received: from proxmox-new.maurer-it.com (localhost.localdomain [127.0.0.1]) by proxmox-new.maurer-it.com (Proxmox) with ESMTP id D152144ACB for ; Thu, 20 Oct 2022 16:20:01 +0200 (CEST) Date: Thu, 20 Oct 2022 16:20:00 +0200 (CEST) From: Wolfgang Bumiller To: Stefan Hanreich Cc: pbs-devel@lists.proxmox.com Message-ID: <693345942.2375.1666275600780@webmail.proxmox.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Priority: 3 Importance: Normal X-Mailer: Open-Xchange Mailer v7.10.5-Rev50 X-Originating-Client: open-xchange-appsuite X-SPAM-LEVEL: Spam detection results: 0 AWL 0.248 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: Re: [pbs-devel] [PATCH proxmox-backup] fix #4301: correctly pass rate limit parameters to API X-BeenThere: pbs-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox Backup Server development discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2022 14:20:05 -0000 > On 10/20/2022 4:11 PM Stefan Hanreich wrote: > > > On 10/20/22 16:06, Wolfgang Bumiller wrote: > > On Thu, Oct 20, 2022 at 03:50:59PM +0200, Stefan Hanreich wrote: > >> > >> > >> On 10/20/22 15:44, Wolfgang Bumiller wrote: > >>> On Thu, Oct 20, 2022 at 02:59:46PM +0200, Stefan Hanreich wrote: > >>>> > >>>> > >>>> On 10/20/22 14:48, Wolfgang Bumiller wrote: > >>>>> On Thu, Oct 20, 2022 at 01:37:31PM +0200, Stefan Hanreich wrote: > >>>>>> With the old code the rate limit parameters got passed in their own > >>>>>> dictionary under the limit key, but the API expects the rate-limit > >>>>>> settings as top-level keys. This commit correctly sets the rate-limit > >>>>>> parameters so the API actually uses them. > >>>>>> > >>>>>> Signed-off-by: Stefan Hanreich > >>>>>> --- > >>>>>> src/bin/proxmox-backup-manager.rs | 14 ++++++++++++-- > >>>>>> 1 file changed, 12 insertions(+), 2 deletions(-) > >>>>>> > >>>>>> diff --git a/src/bin/proxmox-backup-manager.rs b/src/bin/proxmox-backup-manager.rs > >>>>>> index 58e7e33a..cdd1037d 100644 > >>>>>> --- a/src/bin/proxmox-backup-manager.rs > >>>>>> +++ b/src/bin/proxmox-backup-manager.rs > >>>>>> @@ -2,7 +2,7 @@ use std::collections::HashMap; > >>>>>> use std::io::{self, Write}; > >>>>>> use std::str::FromStr; > >>>>>> -use anyhow::Error; > >>>>>> +use anyhow::{Error, format_err}; > >>>>>> use serde_json::{json, Value}; > >>>>>> use proxmox_router::{cli::*, RpcEnvironment}; > >>>>>> @@ -297,7 +297,6 @@ async fn pull_datastore( > >>>>>> "store": store, > >>>>>> "remote": remote, > >>>>>> "remote-store": remote_store, > >>>>>> - "limit": limit, > >>>>>> }); > >>>>>> if remote_ns.is_some() { > >>>>>> @@ -320,6 +319,17 @@ async fn pull_datastore( > >>>>>> args["remove-vanished"] = Value::from(remove_vanished); > >>>>>> } > >>>>>> + let args_map = args > >>>>>> + .as_object_mut() > >>>>>> + .ok_or_else(|| format_err!("args is not an Object"))?; > >>>>> > >>>>> ^ We create the `args` map only a few lines further up, so it would be > >>>>> fine to just `.unwrap()` here. And it would be nicer to keep the access > >>>>> short (iow move the `.as_object_mut()` down to where it's used for `.append()`) > >>>>> > >>>> > >>>> Can replace it with unwrap(), shouldn't be a problem. > >>>> > >>>> The reason why I stored it in a variable was that with a subsequent patch I > >>>> will also append another map to the args, but I could then just call > >>>> .as_object_mut() twice, what do you think? > >>> > >>> I suppose that's fine. If you already know such things while sending a > >>> patch without the followups being part of the same series, you can note > >>> such things after the `---` in the patch mail, that way it won't > >>> needlessly end up in the commit message, but still be visible to the > >>> reviewer. > >>> > >>> Come to think of it, there are a lot of `args[key] = value;` assignments > >>> which could probably benefit from already having the `&mut Map` instead > >>> of the `Value` enum. > >>> > >>> Maybe should change it like this > >>> > >>> - let mut args = json!(...) > >>> + let mut args_value = json(!...); > >>> + let args = args_value.as_object_mut().unwrap(); > >>> > >>> right where it is created, this way the unwrap will stay even closer to > >>> the creation, the remaining assignments already see the object type, and > >>> you can call append, too. > >>> Finally, the `Some(args)` would need to be changed to `Some(args_value)` > >>> in the `post()` call. > >>> > >> > >> I will keep that in mind for future patches, thanks for the info! > >> > >> The problem is when assigning via args[key] = value on a Map, it actually > >> panics if the key doesn't exist in the map [1], so I'm afraid this isn't a > >> possibility unless I'm missing something. > > > > Can be changed to use `.insert()` ;-) > > yes, but I thought that would just be needlessly verbose since all > `args[key] = value` would be replaced with some kind of > > ``` > args.insert( > key.to_string(), > value.into() / json!(value) > ); > ``` > > I can definitely change it to use `insert()` in my subsequent patch if > you want me to - just say the word ;) It's fine. If the parameter list gets too large I'd probably start thinking about putting them in a struct type shared between client & server code and just serialize that once. (That would also get rid of the temporary `limit` Object.)