public inbox for pve-devel@lists.proxmox.com
 help / color / mirror / Atom feed
From: Daniel Kral <d.kral@proxmox.com>
To: pve-devel@lists.proxmox.com
Subject: [PATCH ha-manager 2/2] fix #6084: lrm: allow dropping maintenance with active HA resources
Date: Wed,  8 Jul 2026 10:42:05 +0200	[thread overview]
Message-ID: <20260708084205.69947-3-d.kral@proxmox.com> (raw)
In-Reply-To: <20260708084205.69947-1-d.kral@proxmox.com>

If a node's LRM is in the maintenance state and one of the HA resources
could not be moved to another node, the node's LRM would be kept in the
maintenance state even as the maintenance request on the node is lifted
again.

This happens because the LRM maintenance state branch for any active HA
resources or workers will catch these cases and not advance to the
branch which puts nodes without maintenance requests back into active
state.

Therefore, do advance to the next branch if the maintenance request is
already lifted and the node's LRM can go back to the active state.

The check for is_maintenance_requested() is intentionally put last to
not change the existing execution chain as run_workers() might have some
side-effects on the LRM workers itself.

Signed-off-by: Daniel Kral <d.kral@proxmox.com>
---
 src/PVE/HA/LRM.pm                                 | 7 +++++--
 src/test/test-crm-maintenance-request5/README     | 5 ++---
 src/test/test-crm-maintenance-request5/log.expect | 1 +
 3 files changed, 8 insertions(+), 5 deletions(-)

diff --git a/src/PVE/HA/LRM.pm b/src/PVE/HA/LRM.pm
index 34425653..a0f8fbc4 100644
--- a/src/PVE/HA/LRM.pm
+++ b/src/PVE/HA/LRM.pm
@@ -456,13 +456,16 @@ sub work {
             $haenv->release_ha_agent_lock();
             give_up_watchdog_protection($self);
             $self->set_local_status({ state => 'wait_for_agent_lock' });
-        } elsif ($self->active_service_count() || $self->run_workers()) {
+        } elsif (
+            ($self->active_service_count() || $self->run_workers())
+            && $self->is_maintenance_requested()
+        ) {
             # keep the lock and watchdog as long as not all services cleared the node
             if (!$self->get_protected_ha_agent_lock()) {
                 $self->set_local_status({ state => 'lost_agent_lock' });
             }
         } elsif (!$self->is_maintenance_requested()) {
-            # empty && no maintenance mode && not exited -> need to switch active again
+            # no node maintenance request && not exited -> need to switch active again
             if ($self->get_protected_ha_agent_lock()) {
                 $self->set_local_status({ state => 'active' });
             } else {
diff --git a/src/test/test-crm-maintenance-request5/README b/src/test/test-crm-maintenance-request5/README
index e7fe0d5e..99612321 100644
--- a/src/test/test-crm-maintenance-request5/README
+++ b/src/test/test-crm-maintenance-request5/README
@@ -2,6 +2,5 @@ Test setting the maintenance mode for a node where an HA resource cannot be
 moved to any other node because of migration errors and moving it out of
 maintenance mode again.
 
-Currently, the node will move out of the maintenance mode, but is left stuck in
-maintenance state as it never reached the required state to be empty to be able
-to move to active state again after the maintenance request is lifted.
+The node's LRM is expected to move out of maintenance mode and state again
+after the maintenance request is lifted from the node.
diff --git a/src/test/test-crm-maintenance-request5/log.expect b/src/test/test-crm-maintenance-request5/log.expect
index 90326ef5..a30be92d 100644
--- a/src/test/test-crm-maintenance-request5/log.expect
+++ b/src/test/test-crm-maintenance-request5/log.expect
@@ -49,6 +49,7 @@ err     220    node1/crm: service 'fa:109' - migration failed (exit code 1)
 info    220    node1/crm: service 'fa:109': state changed from 'relocate' to 'started'  (node = node1)
 info    220    node1/crm: relocate service 'fa:109' to node 'node2'
 info    220    node1/crm: service 'fa:109': state changed from 'started' to 'relocate'  (node = node1, target = node2)
+info    221    node1/lrm: status change maintenance => active
 err     221    node1/lrm: service fa:109 not moved (migration error)
 info    240    node1/crm: node 'node1': state changed from 'maintenance' => 'online'
 err     240    node1/crm: service 'fa:109' - migration failed (exit code 1)
-- 
2.47.3





  parent reply	other threads:[~2026-07-08  8:42 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-08  8:42 [PATCH-SERIES ha-manager 0/2] fix #6084: allow dropping maintenance state with active HA resources Daniel Kral
2026-07-08  8:42 ` [PATCH ha-manager 1/2] test: add maintenance test case with stuck HA resource Daniel Kral
2026-07-08  8:42 ` Daniel Kral [this message]
2026-07-08 14:40   ` [PATCH ha-manager 2/2] fix #6084: lrm: allow dropping maintenance with active HA resources Michael Köppl
2026-07-08 14:40 ` [PATCH-SERIES ha-manager 0/2] fix #6084: allow dropping maintenance state " Michael Köppl

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260708084205.69947-3-d.kral@proxmox.com \
    --to=d.kral@proxmox.com \
    --cc=pve-devel@lists.proxmox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal