[pve-devel] health check uri for proxmox web front end?

[Thomas Lamprecht]

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