From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate001.proxmox.com (gate001.proxmox.com [45.144.208.40]) by lore.proxmox.com (Postfix) with ESMTPS id F04E81FF0B3 for ; Wed, 14 Oct 2026 12:52:58 +0200 (CEST) Received: from gate001.proxmox.com (localhost.localdomain [127.0.0.1]) by gate001.proxmox.com (Proxmox) with ESMTP id 5B07F21464; Wed, 14 Oct 2026 12:52:57 +0200 (CEST) Message-ID: <3468f36b-7b96-47b2-ac69-5a757fe77a5c@proxmox.com> Date: Wed, 14 Oct 2026 12:52:52 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH ha-manager v3 10/21] api: resources: migration: support additional migration options To: Daniel Kral , pve-devel@lists.proxmox.com References: <20260918160841.128088-1-f.ebner@proxmox.com> <20260918160841.128088-11-f.ebner@proxmox.com> Content-Language: en-US From: Fiona Ebner In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1791975173089 X-SPAM-LEVEL: Spam detection results: 0 AWL 0.428 Adjusted score from AWL reputation of From: address DMARC_MISSING 0.1 Missing DMARC policy KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment (newer systems) RCVD_IN_DNSWL_MED -2.3 Sender listed at https://www.dnswl.org/, medium trust 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: 34KLQXVO6OUPFSGPYQBNGI3VNGBJNLVG X-Message-ID-Hash: 34KLQXVO6OUPFSGPYQBNGI3VNGBJNLVG X-MailFrom: f.ebner@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: Am 14.10.26 um 9:59 AM schrieb Daniel Kral: > On Tue Oct 13, 2026 at 4:34 PM CEST, Fiona Ebner wrote: >> Am 12.10.26 um 11:59 AM schrieb Daniel Kral: >>> On Fri Sep 18, 2026 at 6:08 PM CEST, Fiona Ebner wrote: >>>> + my $version_info = PVE::Cluster::get_node_kv('version-info'); >>>> + for my $node (sort keys $version_info->%*) { >>>> + my $node_info = eval { JSON::decode_json($version_info->{$node}); }; >>>> + if (my $err = $@) { # warn, but continue >>>> + syslog('warn', "cannot parse version info for $node as JSON - $err"); >>> >>> Shouldn't we fail if it's not possible to determine a node's version? >> >> No, this is deliberate. Updated cluster is the usual situation. An error >> here should not affect the usual situation. I'm choosing to affect the >> unusual situation, where the master happens to be too old and unable to >> report its version properly, which should be rare. The failure is also >> not critical: it will be an ignored CRM command with warnings/errors >> logged until the version can be determined again. > > Yeah, since 'version-info' is broadcasted in the same format since > Proxmox VE 7.1 so that shouldn't be a problem. > >> >> But I will switch the order below and keep submitting a non-JSON CRM >> command if the new style is not actually required. This gives an escape >> hatch. > > This depends if we want to switch to only the JSON CRM command format in > the future, then it would be preferable to always use the new format so > we can switch to it in some future major version, at least for the > migrate command? I don't see the hurry with phasing out the non-JSON variant. We can keep the handling for it for backwards-compat until we have a good reason to drop it. I'd be in favor of reducing potential for issues now, even if it's just in the edge case with old master node+failing version check. But I'll add a reminder to switch to submitting the JSON variant for the next major version, so we can do the first step then.