On Fri, Feb 07, 2025 at 04:59:49 -0000, Harikumar Rajkumar wrote:
> > On Mon, Nov 18, 2024 at 19:24:15 +0530, Harikumar R wrote:
> > I don't think we should do the 'change a subset of' semantics any more.
> > It was proven that it doesn't make sense. Specifically it's not possible
> > to distinguish between "I don't want to change this field" and "I want
> > to delete/revert to default for this field".
> >
> > The users must be instructed to always post the full required config.
>
> If the customer provides only a subset of the throttle group,
> the other fields will remain unchanged.
First let's focus on the libvirt API design:
(deliberately let's not compare this to the old design)
You have the XML configuration, in which if a filed is omitted the
default value will be assumed.
Now if the API is designed so that omitted fields are not touched you
don't have a way to actually return the configuration to the "default
value" via the API. The users then have to edit the XML and restart the
VM to achieve that config.
Thus the only solution where the setter API allows full range of setting
is the one which fully replaces the configuration with the new fields.
This is also something we started to gravitate towards in the API
backing 'virsh update-device'. Originally it tried to not change
settings that were omitted in the input XML but that simply didn't work
for certain thigns and especially for returning to defualt settings.
>Deleting/reverting a field may cause data mismatches between the XML and QEMU.
This must not happen. Libvirt must always update everything so that the
QEMU config is identical to what is requested in the XML.
It is an implementation detail how that is achieved, based on what qemu
provides:
- explicitly request qemu to revert to default
- query the default and set the same value as default
- refuse to do something that is not possible
> We will instruct users to always provide the full required configuration.
The API needs to allow a way that overwrites the full config including a
way to return to the default.
That said you can have a flag which switches the behaviour to "update
fields which were provided to the provided value and leave everything
else untouched" if that is practical to achieve
> Can we have a validation to check the config?
I don't follow which you mean here. As said, if something is not
possible to set in qemu if the API allows it, it needs to be rejected,
so that the state doesn't desync between qemu and libvirt.
