Re: proposal: deprecate -readconfig/-writeconfig

[John Snow <jsnow@redhat.com>]

On 5/14/20 4:56 AM, 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.
> 

Yeah. In this sense, would a json/yaml config file help, under the
premise that you could just cat it into the pipe to configure a machine?

(Assuming we had proper runtime configuration commands, of course.)

> For a less general purpose mgmt app, that targets some specific use
> cases I could imagine people might have used readconfig. Note that
> we have a bunch of documentation that is illustrating usage of
> -readconfig to our users. So it is quite possible we have people
> relying on this feature even though it is incomplete in its coverage
> of options.
> 
> If we deprecate them, the only alternative users have right now is
> to go back to passing CLI args. This works, as this is what libvirt
> has always done, but it isn't pretty to see 1 MB command lines ;-P
> 

Can always write a shim that reads the options from a text file. *shrug*

It still clutters the process list, but there's not much we can do right
now.

> So essentially 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.
> 
> This could justify us removing the feature with no immediate replacement,
> on the basis that would facilitate more important changes that are for
> the greater good of the project long term.
> 
> Overall, I don't object, just cautioning that we should be aware that
> we're likely to have some users of this feature we're conciously going
> to break.
> 
> Regards,
> Daniel
> 

Sometimes I feel like a broken and impartial solution is really worse
than having none. If we don't truly support the read/write config
options, we shouldn't pretend that we do.

Funneling users back to using the CLI is likely the better thing, even
with no replacement.

I realize this is a pretty hostile thing to do in general, though, but
it might truly be the kinder option to start simplifying and unifying
configuration, documentation, and support efforts.

We don't have to actually remove it right away, either. We can just
start sounding the alarms that we're preparing to remove it, and falling
back to using the CLI would be a safe thing to do for now.

--js