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.
