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!
