I have seen that since, but why is not then shoved all into the pve-manager? That's the inconsistency. Since it has all those use (which I do not wish to argue), why is it not treated like e.g. pve-common? There's no pve-common package either. I understand why it's a seprate git repo, not why it is a package.
There's libpve-common-perl package that comes from pve-common that is handled like every other package, but as relatively low level package it itself includes no API endpoints (but lots of supporting and base code for those).
Oh and yeah, I forgot to mention the ha <-> qemu-server and ha <-> container ones, those are also something which we'd like to be able to resolve someday, they are there as start/stop/migrate request to VM/CT CLI/API is redirected to HA, and the LRM in charge of a guest calls the actual lower level start/stop/migrate to execute that.
This could be resolved by a package split, but as its pain is mostly felt on bootstrapping, which is 1) not often done and 2) done by staff with enough packaging and PVE experience to handle that correctly, it wasn't simply due to a small ROI.
But the existence of those does not justify adding more, as they are already too much, but exist due to historic reasons and got already isolated such that the maintenance work is manageable, but that again does not mean that adding more such non-ideal options is fine.
1) softdog is active always
softdog is just the default and fallback, one watchdog is always active not necessarily softdog.
2) watchdog_mux is part of pve-ha-manager and always listens on that socket (so can be triggered)
Yeah, anything that is installable or can be enabled can be triggered. The point is, the watchdog won't be through the HA stack if it was never configured at current boot, which is the default – so this really is not the loaded gun you try to make it seem like.
Stay with the facts, don't shoot from the hips with half knowledge, and we can talk about actual improvements.
3) pve-ha-manager conflicts with watchdog which is PITA on its own if someone does not use HA and wants their own
Yeah, because that would grab
/dev/watchdog, failing watchdog-mux and pve-ha-manager, and PVE simply does not support other watchdogs, which is shown by that dependency. The fix here would be that watchdog-mux can offer a device node that supports the watchdog protocol but goes through itself, would be actually a nice feature that could make it quite useful outside the PVE ecosystem.
1) does not have to start on a node, it can be launched when CRM or LRM was about to get active only
No, as then the watchdog can be already bound by something else. We had socket activation in an early prototype, was removed for a few reasons, this was one of them.
2) when it starts it does not have to start feeding softdog unless it has clients (there's nothing to multiplex when there are none)
see reply to 1), either it starts and binds the watchdog, making it active, or not.
3) could close /dev/watchdog0 orderly when the clients come and go
same here, simple design choice.
1) i can't rely that it will survive upgrades
You can definitively rely on explicitly disabled and especially masked systemd services staying that way.
2) if it's just disabled on some nodes they will be "excluded" from the HA in "not so nice way"
Either one wants a HA cluster or one doesn't, in which case one either disables it in the whole cluster (not required if one never configures HA services), or doesn't do so for the whole cluster.
3) softdog device is still there albeit not active - yes i know i can blacklist the module, then the log is messy with HA stack complaining
The log is not messy if those services are disabled.
So again, can already be done. If you want an easier way, then that's fine to add an enhancement request in for, but saying it's not possible, or that it's activated by default is both just bogus.
