From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [IPv6:2a01:7e0:0:424::9]) by lore.proxmox.com (Postfix) with ESMTPS id 6683B1FF140 for ; Fri, 27 Mar 2026 10:34:50 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id A257B39; Fri, 27 Mar 2026 10:35:13 +0100 (CET) Date: Fri, 27 Mar 2026 10:34:38 +0100 From: Arthur Bied-Charreton To: Fiona Ebner Subject: Re: [PATCH pve-manager 4/8] ui: Add basic custom CPU model editor Message-ID: References: <20260312084021.124465-1-a.bied-charreton@proxmox.com> <20260312084021.124465-5-a.bied-charreton@proxmox.com> <3pvqrvjm7srqfaaok3o7ner4xa6s3sdqlw5thrhhxigdpvl4w5@wy5hunbsnjn7> <17988b55-43bc-46af-9067-ef635365b096@proxmox.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <17988b55-43bc-46af-9067-ef635365b096@proxmox.com> X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1774604029334 X-SPAM-LEVEL: Spam detection results: 0 AWL 0.781 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DMARC_MISSING 0.1 Missing DMARC policy KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment 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: VIAK36GHWIIMDSFQJPIC3FNK4V7BMSVV X-Message-ID-Hash: VIAK36GHWIIMDSFQJPIC3FNK4V7BMSVV X-MailFrom: a.bied-charreton@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 CC: pve-devel@lists.proxmox.com X-Mailman-Version: 3.3.10 Precedence: list List-Id: Proxmox VE development discussion List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: On Fri, Mar 27, 2026 at 10:32:52AM +0100, Fiona Ebner wrote: > Am 27.03.26 um 10:22 AM schrieb Arthur Bied-Charreton: > > On Thu, Mar 26, 2026 at 04:10:34PM +0100, Fiona Ebner wrote: > >> Am 12.03.26 um 9:40 AM schrieb Arthur Bied-Charreton: > >> > > [...] > >>> + { > >>> + xtype: 'CPUModelSelector', > >>> + fieldLabel: gettext('Reported Model'), > >> > >> What about 'Base Model' with a tooltip that it's reported to the guest > >> (if that is even necessary)? I feel like 'Reported Model' doesn't make > >> it clear that the rest of the configuration is applied based off that model. > >> > > I agree that "Base Model" makes more sense than "Reported Model", > > however the latter is better aligned with the SectionConfig key. > > > > In order for pvesh to be consistent with the UI, we would need to expose > > `base-model` in the `custom-cpu-models` API and translate it to > > `reported-model` in the handlers. Which would however still not be > > consistent with the actual config file content and might lead to confusion > > for users who are/were manually editing the file. > > > > `reported-model` seems to be quite sticky, changing the SectionConfig > > key looks like a pretty big refactor? > > > > What do you think? Would we be okay with the naming inconcistency, and > > if so at what level should the break happen? Otherwise we could keep > > "Reported Model" and add a tooltip explaining it to avoid confusion. > > > > You don't need to change it in the backend. There's no real need for > user-facing strings in the UI to be consistent with property keys in the > API schema. Things may be called differently in the UI if those names > are better from a user perspective. Okay, will only change it in the UI then, thanks!