public inbox for pve-devel@lists.proxmox.com
 help / color / mirror / Atom feed
From: Fiona Ebner <f.ebner@proxmox.com>
To: Thomas Lamprecht <t.lamprecht@proxmox.com>, pve-devel@lists.proxmox.com
Subject: Re: [PATCH ha-manager v2 3/4] fix #2751: implement disarm-ha and arm-ha for safe cluster maintenance
Date: Wed, 25 Mar 2026 16:50:07 +0100	[thread overview]
Message-ID: <aa320745-2e4a-4b24-b284-9336396797b2@proxmox.com> (raw)
In-Reply-To: <20260321234350.2158438-4-t.lamprecht@proxmox.com>

Am 22.03.26 um 12:57 AM schrieb Thomas Lamprecht:
> +    if ($mode eq 'freeze') {
> +        for my $sid (sort keys %$ss) {
> +            my $sd = $ss->{$sid};
> +            my $state = $sd->{state};
> +            next if $state eq 'freeze'; # already frozen
> +            if (
> +                $state eq 'started'
> +                || $state eq 'stopped'
> +                || $state eq 'request_stop'
> +                || $state eq 'request_start'
> +                || $state eq 'request_start_balance'
> +                || $state eq 'error'

Should it really happen for the 'error' state too? Because when
re-arming, the state will become 'started':

Mar 25 16:20:06 pve9a1 pve-ha-crm[242553]: disarm: freezing service
'vm:400' (was 'error')
...
Mar 25 16:20:36 pve9a1 pve-ha-crm[242553]: service 'vm:400': state
changed from 'freeze' to 'started'

Which feels rather surprising to me. For comparison, after a cold
cluster start, services in 'error' state are not (attempted to be)
started either.

> +            ) {
> +                $haenv->log('info', "disarm: freezing service '$sid' (was '$state')");
> +                delete $sd->{$_} for grep { !$keep_keys{$_} } keys %$sd;
> +                $sd->{state} = 'freeze';
> +                $sd->{uid} = compute_new_uuid('freeze');
> +            }
> +        }




  parent reply	other threads:[~2026-03-25 15:50 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-21 23:42 [PATCH ha-manager v2 0/4] fix #2751: implement disarm/arm HA for safer " Thomas Lamprecht
2026-03-21 23:42 ` [PATCH ha-manager v2 1/4] sim: hardware: add manual-migrate command for ignored services Thomas Lamprecht
2026-03-21 23:42 ` [PATCH ha-manager v2 2/4] api: status: add fencing status entry with armed/standby state Thomas Lamprecht
2026-03-21 23:42 ` [PATCH ha-manager v2 3/4] fix #2751: implement disarm-ha and arm-ha for safe cluster maintenance Thomas Lamprecht
2026-03-23 13:04   ` Dominik Rusovac
2026-03-25 15:50   ` Fiona Ebner [this message]
2026-03-27  1:17     ` Thomas Lamprecht
2026-03-26 16:02   ` Daniel Kral
2026-03-26 23:15     ` Thomas Lamprecht
2026-03-27 10:21       ` Daniel Kral
2026-03-21 23:42 ` [PATCH ha-manager v2 4/4] api: status: add disarm-ha and arm-ha endpoints and CLI wiring Thomas Lamprecht
2026-03-23 13:05 ` [PATCH ha-manager v2 0/4] fix #2751: implement disarm/arm HA for safer cluster maintenance Dominik Rusovac
2026-03-25 12:06 ` applied: " Thomas Lamprecht

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=aa320745-2e4a-4b24-b284-9336396797b2@proxmox.com \
    --to=f.ebner@proxmox.com \
    --cc=pve-devel@lists.proxmox.com \
    --cc=t.lamprecht@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