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

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

On Wed Apr 15, 2026 at 3:32 PM CEST, Dominik Rusovac wrote:
> thx for the comments! I will send a v3
>
> On Wed Apr 15, 2026 at 2:32 PM CEST, Dominik Csapak wrote:
>> what i miss with using these is some feedback when i activated them.
>>
>> This is probably more due to the backend decision, but
>> when clicking arm/disarm, there is nothing happening in the gui at
>> first, no spinning icon, no change in state..
>
> regarding feedback after activating either of them: one can see the
> Status changing in the Status panel, which exactly traces what's going
> on for every node, in particular it reveals the armed-state in the
> Status of fencing
>
> if that's not enough feedback, I'd look into other possible solutions in
> more detail
>
>>
>> I think there are a few possible solutions on this, but
>> i'm not super deep in the ha stack, so sorry in advance if
>> some can't work:
>> * use a worker that waits for the change of the ha state, e.g.
>>    via polling. this could directly be shown in the gui
>> * mark the requested state immediately somewhere and return
>>    it with the overall ha state, so we  see in the gui what is happening
>> * 'fake' the progress until we see a status change
>>    (i don't really like this, since it's prone to errors when e.g.
>>     one admin disarms, the other arms again, but the gui does not
>>     get an updated state in the meantime)

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).

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.

[snip]

>>> +                {
>>> +                    text: gettext('Disarm HA'),
>>> +                    iconCls: 'fa fa-unlink',
>>> +                    bind: {
>>> +                        disabled: '{haDisarmed}',
>>> +                    },
>>> +                    menu: [
>>> +                        {
>>> +                            text: gettext('Freeze'),
>>> +                            iconCls: 'fa fa-snowflake-o',
>>> +                            mode: 'freeze',
>>> +                            handler: 'handleDisarmButton',
>>> +                        },
>>> +                        {
>>> +                            text: gettext('Ignore'),
>>> +                            iconCls: 'fa fa-eye-slash',
>>> +                            mode: 'ignore',
>>> +                            handler: 'handleDisarmButton',
>>> +                        },
>>> +                    ],
>>> +                },
>>> +                {
>>> +                    text: gettext('Arm HA'),
>>> +                    iconCls: 'fa fa-link',
>>> +                    bind: {
>>> +                        disabled: '{!haDisarmed}',
>>> +                    },
>>> +                    handler: 'handleArmButton',
>>> +                },
>>> +            ],
>>
>> i'm not totally against having two buttons here, but since
>> there is always only one or the other active, wouldn't
>> it make more sense to hide the button that
>> can't do anything? (though i admit we do most often show the
>> unusable buttons across our gui, so it's fine too)
>>
>
> tbh, I just tried to adhere to what I found in other places of the gui
>
> if hiding the unusable button is more desirable, I can go for that
> option instead
>

IMO this should be consistent with the other panels (e.g. OSD where we
also have mutually exclusive buttons like 'Start'/'Stop' and
'In'/'Out').

I think the nice thing about having both visible at the same time is
that users can immediately see where they have to click when they want
to arm the HA stack again and vice versa and don't have to find out by a
rather 'dangerous' action. Especially since the buttons have different
behaviors with disarming having two modes while arming being a single,
simple button.

>> At least i would probably switch the position of these,
>> since the more  (for the lack of a better word) 'affirming' action
>> is usually at the beginning (like 'add' or 'start') and the other
>> options comes later (like 'remove' or 'shutdown')
>>
>> so
>>
>> | Arm | Disarm |
>>
>> reads more logical to me than
>>
>> | Disarm | Arm |
>>

Nice! +1