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 EA8C51FF0ED for ; Fri, 31 Jul 2026 15:43:09 +0200 (CEST) Received: from gate001.proxmox.com (localhost.localdomain [127.0.0.1]) by gate001.proxmox.com (Proxmox) with ESMTP id B8F4221542; Fri, 31 Jul 2026 15:43:09 +0200 (CEST) Message-ID: <45579630-54b9-4f3d-81e3-efa9e67a59b2@proxmox.com> Date: Fri, 31 Jul 2026 15:43:06 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Beta Subject: Re: [RFC qemu-server 4/4] remote migrate: add precondition check endpoint To: Fiona Ebner , pve-devel@lists.proxmox.com References: <20260721115827.163442-1-e.fastermann@proxmox.com> <20260721115827.163442-5-e.fastermann@proxmox.com> Content-Language: en-US From: Erik Fastermann In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1785505376772 X-SPAM-LEVEL: Spam detection results: 0 AWL 0.944 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_LOW -0.7 Sender listed at https://www.dnswl.org/, low 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: LSLYFPDNSKGR3RVBP4TX76TCI3LN45GC X-Message-ID-Hash: LSLYFPDNSKGR3RVBP4TX76TCI3LN45GC X-MailFrom: e.fastermann@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 21.07.26 um 1:58 PM schrieb Erik Fastermann: >> + storage => get_standard_option( >> + 'pve-storage-id', >> + { >> + description => "Optional associated storage.", >> + optional => 1, >> + }, >> + ), > > Is the idea to include the storage ID to represent such findings > differently from other warnings/errors in the UI? The field is meant as an extension of the code field for machine consumers, so a caller can tell which object a finding refers to without parsing the message. The UI will most likely need it: The message we return cannot always be translated AFAIK, so the UI has to build its own string from the code and needs the storage ID separately to fill it in. Storage is currently the only such field, because it is the only one the existing checks need. Further fields can be added the same way as more checks arrive.