Re: proposal: deprecate -readconfig/-writeconfig

[Markus Armbruster]

Paolo Bonzini <address@hidden> writes:

> On 14/05/20 10:56, Daniel P. Berrangé wrote:
>> On Thu, May 14, 2020 at 10:09:21AM +0200, Paolo Bonzini wrote:
>>> IMHO configuration files are in general a failed experiment.  In
>>> practice, they do not add much value over just a shell script because
>>> they don't allow configuring all QEMU options, they are very much fixed
>>> (by their nature).  I think it's more or less agreed that they are not
>>> solving any problem for higher-level management stacks as well; those
>>> would prefer to configure the VM via QMP or another API.
>>>
>>> So, any objections to deprecating -readconfig and -writeconfig?
>> 
>> Libvirt would like to have a config file for QEMU, but it would have
>> to be one that actually covers all the config options QEMU supports,
>> and ideally using a data format in common with that used for runtime
>> changes. So for libvirt's needs the current readconfig is entirely
>> useless.
>
> Yes, this is what I was thinking about.
>
>> For a less general purpose mgmt app, that targets some specific use
>> cases I could imagine people might have used readconfig. [...]
>> If we deprecate them, the only alternative users have right now is
>> to go back to passing CLI args. [...] We'd be deciding to kill the
>> feature with no direct replacement, even though it is potentially
>> useful in some limited scenarios.
>> 
>> If we have a general strategy to eliminate QemuOpts and move entirely
>> to QAPI based config, then I can see -readcofig/-writeconfig may be
>> creating a burden of back compatibility on maintainers.
>
> I don't see QemuOpts going away anytime soon, but I do see more QMP/QAPI
> and less command line in the future as far as management tools are
> concerned.  QemuOpts and HMP will remain for direct usage, for the
> foreseeable future.

I'd prefer not to have two separate configuration infrastructures.

> So I guess we can keep -readconfig but deprecate, or even remove,
> -writeconfig.

Deprecate both as stable interfaces, remove neither.