Re: proposal: deprecate -readconfig/-writeconfig

["Daniel P. Berrangé" <berrange@redhat.com>]

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.

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

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
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|