Re: [PATCH manager v2] ui: ha: add disarm/re-arm button

["Daniel Kral" <d.kral@proxmox.com>]

On Thu Apr 16, 2026 at 11:20 AM CEST, Thomas Lamprecht wrote:
> On 16/04/2026 09:32, Daniel Kral wrote:
>> Good catch!
>> 
>> Hm, we also more-or-less fake the instant state change of the HA
>> resources: If the HA resource's state is changed in the web interface,
>> which is written to the resources.cfg file, we reload the HA status
>> model right after it. The status API then returns some interleaved
>> version, which instantly respects the requested state from the config
>> (see PVE::HA::Tools::get_verbose_service_state()).
>> 
>> The reason this doesn't happen for the disarm/arm state is because these
>> need to wait to be processed by the HA Manager first... The same goes
>> for other things handled with CRM commands, such things as migrating HA
>> resources or putting nodes in maintenance mode. But for these things we
>> can't really fake it because whether these actions are accepted at all
>> depend on the HA Manager entirely.
>> 
>> Ideally, we would have some callback mechanism here (would benefit some
>> other things for the HA stack as well).
>
> We could compare the request state (config + queued CRM commands) with
> the current status and show pending states, with that we should be able
> to solve better relaying any such queued changes, be it resource level
> ones or HA LRM/CRM ones.
>

Right, now that you say it, most of the queued CRM commands do not have
much logic we would need to 'emulate' for the Status API so those queued
changes can be relayed quicker to the user, good idea!

>> In the meantime I think a worker polling the ha state for the requested
>> condition would do good here to give users feedback when the disarming
>> process is finished. This should also handle if the HA Manager doesn't
>> process the command at all for some reason.
>
> can be OK, but rather more work and also "just" a entry in the task log,
> if a lot is going on in a cluster, i.e. multiple tasks are running, this
> might be easily missed as well. Biggest benefit of it would be actually
> having some more visible task log of whom triggered a HA change when, as
> the system log is not fully complete (missing user) and as much more gets
> logged there from the whole system it's also more crowded.
>
> Such a task log would IMO a orthogonal change to the showing pending
> changes one though, and might be better solved with a targeted audit
> system/log, as adding a task log just for that might be a bit overkill and
> slightly misusing the task log system for something it wasn't exactly
> designed for (one can squint and it will seem appropriate, but a structured
> audit log would be much better and solve some other pain points and user
> requests). Would be nice to have, but not a blocker for this. The pending
> changes is blowing up scope a bit and given that we already have the
> pattern for resource request state changes, I'd also not see that as
> blocker here, but definitively should get improved soon.

I could have phrased my response a little better as I meant polling in
the web interface here. The tasks could be nice too as you said but
should not block this patch here at all and I fully agree that such a
feature should be handled in another series.