* [pve-devel] health check uri for proxmox web front end?
@ 2023-06-22 22:33 Wolf Noble
2023-06-23 6:59 ` Thomas Lamprecht
0 siblings, 1 reply; 2+ messages in thread
From: Wolf Noble @ 2023-06-22 22:33 UTC (permalink / raw)
To: pve-devel
hi all!
I have looked thru the api docs, and forums, and haven’t found a solution myself yet.
I’m looking for a lightweight uri to assess the health of a proxmox node for the purposes of having the proxmox web ui behind a loadbalanced vip
( haproxy run on opnsense )
Im aware of the existing api face, however what exists now requires authentication, and seems a little heavy for my intended use:
(hey, you alive? yes? cool! i’ll check again in a couple seconds)
Ideally, there’d be a super lightweight check face that responds with a 200/ok, perhaps even with some light metadata cached from other normal operations…
the ideal (from my perspective) would be a target endpoint that requires no auth, but the authorized calling hosts must be explicitly whitelisted for the node to respond to the query.
ideally logging of ‘good’ state request responses would be optional.
ideally, data included in the response, and it’s acceptable freshness would also be configurable.. but i don’t want to overcomplicate things either….
does such a mechanism exist already, and I just couldn’t find it?
if not, is there already a feature request, or someplace this was already discussed?
—- TANGENT
another thought I had which seemed totally tangental at first blush was wondering if the web ui for a cluster could additionally (ie not exclusively) be served by a different class of node (i was thinking pi4’s … ) the thought was that by having an ‘administrative function only’ cluster node type could be a way to as a way to slowly build arm64 support…
… as i imagine this could be useful, but getting EVERYTHING working on a dif arch is a monumentally complex task not likely to bear much fruit terribly quickly, but I digress…
tia!
I’ve been really happy with my proxmox experience over the last several years….
thanks for all the hard work you’ve done keeping proxmox such a stable abstraction layer… its greatly appreciated.
❤️🐺W
[= The contents of this message have been written, read, processed, erased, sorted, sniffed, compressed, rewritten, misspelled, overcompensated, lost, found, and most importantly delivered entirely with recycled electrons =]
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: [pve-devel] health check uri for proxmox web front end?
2023-06-22 22:33 [pve-devel] health check uri for proxmox web front end? Wolf Noble
@ 2023-06-23 6:59 ` Thomas Lamprecht
0 siblings, 0 replies; 2+ messages in thread
From: Thomas Lamprecht @ 2023-06-23 6:59 UTC (permalink / raw)
To: Proxmox VE development discussion, Wolf Noble
Hi,
Am 23/06/2023 um 00:33 schrieb Wolf Noble:
> Im aware of the existing api face, however what exists now requires authentication, and seems a little heavy for my intended use:
>
> (hey, you alive? yes? cool! i’ll check again in a couple seconds)
>
> Ideally, there’d be a super lightweight check face that responds with a 200/ok, perhaps even with some light metadata cached from other normal operations…
We are normally reluctant when adding world-readable API calls, but one
could imagine something like the "ping" one from PBS:
https://pbs.proxmox.com/docs/api-viewer/index.html#/ping
>
> the ideal (from my perspective) would be a target endpoint that requires no auth, but the authorized calling hosts must be explicitly whitelisted for the node to respond to the query.
>
> ideally logging of ‘good’ state request responses would be optional.
>
> ideally, data included in the response, and it’s acceptable freshness would also be configurable.. but i don’t want to overcomplicate things either….
>
> does such a mechanism exist already, and I just couldn’t find it?
Well, you already got a proxy in-between and API tokens exists [0][1], so you
can always make a API path world-readable to all that can access the reverse
proxy by adding a separate "virtual" URL path, that doesn't clash with existing
Proxmox VE ones, and make that point to the, e.g., node status endpoint [2] and
make it add the API token, restricted to just auditing, on any request as
Authorization header.
[0]: https://pve.proxmox.com/pve-docs/chapter-pveum.html#pveum_tokens
[1]: https://pve.proxmox.com/wiki/Proxmox_VE_API#API_Tokens
[2]: https://pve.proxmox.com/pve-docs/api-viewer/#/nodes/{node}/status
>
> if not, is there already a feature request, or someplace this was already discussed?
>
Adding some health API call, that is less focused on the underlying host system
metrics, and more a central point to check if API and core services are up
could be done, albeit certainly with requiring audit permissions on anything but
a simple "yes API is there" (which can be figured out anyway by simply doing any
API request, as even getting a permission denied is a good sign that API is working).
Anyhow, we should check closely what this endpoint should return and if it wouldn't
be already covered by an existing ones (sorry, I do not have every one memorised ^^)
but the "/nodes/{node}/services" [3] might be also a candidate.
[3]: https://pve.proxmox.com/pve-docs/api-viewer/index.html#/nodes/{node}/services
> —- TANGENT
>
> another thought I had which seemed totally tangental at first blush was wondering if the web ui for a cluster could additionally (ie not exclusively) be served by a different class of node (i was thinking pi4’s … ) the thought was that by having an ‘administrative function only’ cluster node type could be a way to as a way to slowly build arm64 support…
> … as i imagine this could be useful, but getting EVERYTHING working on a dif arch is a monumentally complex task not likely to bear much fruit terribly quickly, but I digress…
If we do another architecture then with all of Proxmox VE's as otherwise the stream
of confusion and feature request will never end.
FWIW, we evaluated arm64 in 2016, and the codebase is partially still containing the
fundamentals for that, so community projects like Pimox [3] can exist, but for us
then the performance, boot situation and availability of server hardware was just
rather to disappointing them - and while the latter has improved a bit in recent
time, the boot situation and HW support is still rather bare bones.
[4] https://github.com/pimox/pimox7
While not totally ruling some form of arm64 support out for the future, we're eyeing
more towards RISC-V, an actual open architecture.
> tia!
> I’ve been really happy with my proxmox experience over the last several years….
>
> thanks for all the hard work you’ve done keeping proxmox such a stable abstraction layer… its greatly appreciated.
thank you for your kind words!
regards,
Thomas
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2023-06-23 7:00 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-06-22 22:33 [pve-devel] health check uri for proxmox web front end? Wolf Noble
2023-06-23 6:59 ` Thomas Lamprecht
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox