From: "DERUMIER, Alexandre" <alexandre.derumier@groupe-cyllene.com>
To: "pve-devel@lists.proxmox.com" <pve-devel@lists.proxmox.com>,
"d.csapak@proxmox.com" <d.csapak@proxmox.com>,
"aderumier@odiso.com" <aderumier@odiso.com>
Subject: Re: [pve-devel] [PATCH-SERIES pve-http-server/pve-manager] fix#4689: rewrite_uri: autofind nodename for qemu/lxc
Date: Wed, 31 May 2023 14:05:56 +0000 [thread overview]
Message-ID: <dd9e5798ec60f391938436304a58fbacb465b202.camel@groupe-cyllene.com> (raw)
In-Reply-To: <ef020f53-4225-0a2a-221a-941567ead319@proxmox.com>
>
>
> hi, while this can work, it introduces a very specific rewriting into
> the
> http server, which might not be obvious and AFAICT won't show up in
> the
> auto-generated api docs?
>
yes, indeed, it doesnt show up in the doc.
> wouldn't it be better to have some api calls defined for real
> (the ones used most often for example) that make use of the
> proxyto_callback method instead?
>
I'm quoting Fabian from bugzilla:
"
Fabian Grünbichler 2023-04-24 13:48:07 CEST
yeah, some parts of the machinery are already in place, e.g., it's
possible to define a "proxyto_callback" that gets called instead of
resolving proxyto straight via the parameter. AFAICT that is not used
anywhere though ;)
probably it would mean caching the vmlist in each http server worker to
avoid expensive queries, plus implementing filtering of the vmid list
for the requesting user/token since we'd not want to leak existence or
location of guests that the user doesn't have access to.
"
So, it seem that Fabian have same opinion than you.
I was doing a simply rewrite to keep it simple, but
I'll have a look at proxyto_callback.
(BTW, vmlist don't seem to be so slow, i'm around 10 extra ms. I don't
think it need to be cached. (it's still faster than doing 1
cluster/ressource api call to find the node + the final call).
> that way they would at least show up in the api documentation,
> even though it's probably a bit of code duplication
> (altough we could maybe just insert the api at a different place
> and do some perl magic refactoring to have it once
> with node parameter and once without?)
>
> or does that seem like a bad idea?
>
prev parent reply other threads:[~2023-05-31 14:06 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-31 11:19 Alexandre Derumier
2023-05-31 11:19 ` [pve-devel] [PATCH pve-http-server 1/1] anyevent: add rewrite_uri Alexandre Derumier
2023-05-31 11:19 ` [pve-devel] [PATCH pve-manager 1/1] httpserver: add rewrite uri for /nodes/(qemu/lxc)/<vmid> Alexandre Derumier
2023-05-31 11:49 ` [pve-devel] [PATCH-SERIES pve-http-server/pve-manager] fix#4689: rewrite_uri: autofind nodename for qemu/lxc Wolfgang Bumiller
2023-05-31 14:12 ` DERUMIER, Alexandre
2023-05-31 13:19 ` Dominik Csapak
2023-05-31 14:05 ` DERUMIER, Alexandre [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=dd9e5798ec60f391938436304a58fbacb465b202.camel@groupe-cyllene.com \
--to=alexandre.derumier@groupe-cyllene.com \
--cc=aderumier@odiso.com \
--cc=d.csapak@proxmox.com \
--cc=pve-devel@lists.proxmox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal