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 639E269B9D for ; Wed, 15 Sep 2021 07:27:06 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 5219D14BFD for ; Wed, 15 Sep 2021 07:26:36 +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) server-digest SHA256) (No client certificate requested) by firstgate.proxmox.com (Proxmox) with ESMTPS id 2CFE514BEF for ; Wed, 15 Sep 2021 07:26:35 +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 E9BBA44888 for ; Wed, 15 Sep 2021 07:26:34 +0200 (CEST) Message-ID: <34eabcdc-5ec1-4a24-526f-7ad005bbf739@proxmox.com> Date: Wed, 15 Sep 2021 07:25:54 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:93.0) Gecko/20100101 Thunderbird/93.0 Content-Language: en-US To: Proxmox Backup Server development discussion , Dominik Csapak , Hannes Laimer References: <20210909134819.2082605-1-d.csapak@proxmox.com> <9128b335-2f1b-5390-57c4-72f36051d8b9@proxmox.com> <84271615-32d7-9ada-372a-141d05210406@proxmox.com> From: Thomas Lamprecht In-Reply-To: <84271615-32d7-9ada-372a-141d05210406@proxmox.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-SPAM-LEVEL: Spam detection results: 0 AWL 1.105 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 -1.969 Looks like a legit reply (A) POISEN_SPAM_PILL 0.1 Meta: its spam POISEN_SPAM_PILL_1 0.1 random spam to be learned in bayes POISEN_SPAM_PILL_3 0.1 random spam to be learned in bayes 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/proxmox-backup] add 'pbs-shell' tool 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: Wed, 15 Sep 2021 05:27:06 -0000 disclaimer: I had half an answer here but missed to send it out soon enou= gh, it's somewhat obsolete due to your v2 but also does not hurt to have on the list so sti= ll sending it.. On 13.09.21 12:38, Dominik Csapak wrote: > thanks for testing! >=20 > On 9/13/21 11:36, Hannes Laimer wrote: >> I just noticed two things while testing: >> =C2=A0 - if an endpoint expects a parameter called 'path'(e.g. POST /c= onfig >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 /datastore), the parameter conflicts wi= th the api path itself >=20 > i'll fix it in the v2 by renaming the variable to 'api-path'. or > should i prefix it with 'pbs-shell' or something? > (it must be something that will not occur in the normal api) meh... Ideally we'd use something that the API probably won't be allowed = to use any time in the future (e.g., =F0=9F=9B=A0=EF=B8=8F ;P). But, `api-path` sounds all right, it's unlikely to be used anytime soon, = and even if we can think through a better solution then, it's a fixed argumen= t any way I figure; so adapting that wouldn't be an actual breaking change. So your v2 is fine. > while i think it *would* be better if we let the proxy/daemon > start the worker, there is no way to detect api calls > that start a worker before actually executing it... > since it's *only* a debug tool, its still fine i think.. I (low-priority) planned to add an actual UPID "type" in PVE since a bit = for API calls that return a worker, doing so in PBS could be used as indicati= on that a endpoint may return a worker. >=20 > alternatively, we can switch to a http client for executing > the api entirely... In that case I'd really like to produce a full-feature API client crate t= hat can also cope with PVE/PMG (not much to change there). We need that anywa= y for future projects and it shouldn't be to hard, can be somewhat modeled after the pve-api-client perl thingy in API and semantics; it would be gr= eat though if it could cope with either hyper or something simple & sync like= ureq (once the native-tls support pull-request is merged).