From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate001.proxmox.com (gate001.proxmox.com [IPv6:2a0f:8001:1:32::40]) by lore.proxmox.com (Postfix) with ESMTPS id DC4AE1FF09C for ; Mon, 19 Oct 2026 14:35:49 +0200 (CEST) Received: from gate001.proxmox.com (localhost.localdomain [127.0.0.1]) by gate001.proxmox.com (Proxmox) with ESMTP id 41DBC215D4; Mon, 19 Oct 2026 14:35:46 +0200 (CEST) Message-ID: <67ef43f0-591f-4e91-9275-e09e1489e4fa@proxmox.com> Date: Mon, 19 Oct 2026 14:35:39 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH ha-manager v4 14/27] api: resources: migration: support additional migration options To: Daniel Kral , pve-devel@lists.proxmox.com References: <20261015125112.174954-1-f.ebner@proxmox.com> <20261015125112.174954-15-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: 1792413339148 X-SPAM-LEVEL: Spam detection results: 0 AWL 0.384 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: P6QX3TRTH4OMIDLRJA4HBD7BANSKH2H2 X-Message-ID-Hash: P6QX3TRTH4OMIDLRJA4HBD7BANSKH2H2 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 16.10.26 um 11:54 AM schrieb Daniel Kral: > On Thu Oct 15, 2026 at 2:50 PM CEST, Fiona Ebner wrote: >> src/PVE/API2/HA/Resources.pm | 110 ++++++++++++++++++++++++++++++----- >> src/PVE/HA/Resources.pm | 1 + >> 2 files changed, 97 insertions(+), 14 deletions(-) >> >> diff --git a/src/PVE/API2/HA/Resources.pm b/src/PVE/API2/HA/Resources.pm >> index b96572b..6a97b2f 100644 >> --- a/src/PVE/API2/HA/Resources.pm >> +++ b/src/PVE/API2/HA/Resources.pm >> @@ -3,15 +3,20 @@ package PVE::API2::HA::Resources; >> use strict; >> use warnings; >> >> +use JSON qw(); >> + >> +use PVE::Exception qw(raise_param_exc); >> use PVE::SafeSyslog; >> use PVE::Tools qw(extract_param); >> use PVE::Cluster; >> use PVE::HA::Config; >> +use PVE::HA::Env::PVE2; > > Why depend on PVE2 here? For registering the resource plugins. I'll add a comment. > >> use PVE::HA::Resources; >> use HTTP::Status qw(:constants); >> use Storable qw(dclone); >> use PVE::JSONSchema qw(get_standard_option); >> use PVE::RPCEnvironment; >> +use PVE::RESTEnvironment qw(log_warn); >> >> use PVE::RESTHandler; >> >> @@ -34,6 +39,49 @@ my $api_copy_config = sub { >> return $scfg; >> }; >> >> +my sub migrate_json_properties { >> + my ($type) = @_; >> + my $plugin = PVE::HA::Resources->lookup($type); >> + return $plugin->migrate_json_properties(); >> +} >> + >> +my sub json_crm_command_is_supported { > > nit: should probably include _motion to specify that it only checks > whether the migrate JSON command is supported The intention is to extend it later when another JSON command becomes available, but fair enough, it can always be renamed later on :) > >> + PVE::Cluster::cfs_update(); >> + 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 = $@) { >> + # An updated cluster is the usual situation. An error here should not affect the usual >> + # situation. The unusual situation, where the master is too old and unable to report its >> + # version properly is rare. Submitting a JSON CRM to such a master will lead to warnings >> + # and the command being ignored. Note that migration without extra parameters also still >> + # works. >> + log_warn("failed check for migration options support - cannot parse version info for" >> + . " node '$node' - $err"); >> + } elsif (!PVE::Cluster::pvecfg_min_version($node_info->{version}, 9, 2, 22)) { >> + return 0; >> + } >> + } >> + >> + return 1; >> +} >> + >> +my sub json_crm_command_is_applicable { > > nit: should probably include _motion to specify that it only checks > whether the migrate JSON command is applicable Ack