[pbs-devel] [PATCH proxmox/proxmox-backup] add 'pbs-shell' tool

Thomas Lamprecht t.lamprecht at proxmox.com
Wed Sep 15 07:25:54 CEST 2021


disclaimer: I had half an answer here but missed to send it out soon enough, it's somewhat
obsolete due to your v2 but also does not hurt to have on the list so still sending it..

On 13.09.21 12:38, Dominik Csapak wrote:
> thanks for testing!
> 
> On 9/13/21 11:36, Hannes Laimer wrote:
>> I just noticed two things while testing:
>>   - if an endpoint expects a parameter called 'path'(e.g. POST /config
>>       /datastore), the parameter conflicts with the api path itself
> 
> 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., 🛠️ ;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 argument 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 indication
that a endpoint may return a worker.

> 
> 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 that
can also cope with PVE/PMG (not much to change there). We need that anyway
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 great
though if it could cope with either hyper or something simple & sync like
ureq (once the native-tls support pull-request is merged).






More information about the pbs-devel mailing list