From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [IPv6:2a01:7e0:0:424::9]) by lore.proxmox.com (Postfix) with ESMTPS id 06EB71FF13C for ; Thu, 16 Apr 2026 12:00:00 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id C7357692; Thu, 16 Apr 2026 11:59:57 +0200 (CEST) Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Thu, 16 Apr 2026 11:59:19 +0200 Message-Id: Subject: Re: [PATCH manager v2] ui: ha: add disarm/re-arm button From: "Daniel Kral" To: "Thomas Lamprecht" , "Dominik Rusovac" , "Dominik Csapak" , X-Mailer: aerc 0.21.0-136-gdb9fe9896a79-dirty References: <20260415064118.33290-1-d.rusovac@proxmox.com> <900084a5-9466-4a98-b653-2c97fc863f38@proxmox.com> In-Reply-To: X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1776333481264 X-SPAM-LEVEL: Spam detection results: 0 AWL 0.078 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DMARC_MISSING 0.1 Missing DMARC policy KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment RCVD_IN_VALIDITY_CERTIFIED_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. RCVD_IN_VALIDITY_RPBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. RCVD_IN_VALIDITY_SAFE_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record Message-ID-Hash: CJRFWTMZXITOCDCRBLYSURCKAFN6GUAV X-Message-ID-Hash: CJRFWTMZXITOCDCRBLYSURCKAFN6GUAV X-MailFrom: d.kral@proxmox.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; loop; banned-address; emergency; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.10 Precedence: list List-Id: Proxmox VE development discussion List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: On Thu Apr 16, 2026 at 11:20 AM CEST, Thomas Lamprecht wrote: > On 16/04/2026 09:32, Daniel Kral wrote: >> Good catch! >>=20 >> 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()). >>=20 >> 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. >>=20 >> 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 an= d > slightly misusing the task log system for something it wasn't exactly > designed for (one can squint and it will seem appropriate, but a structur= ed > 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.