From: Markus Armbruster <armbru@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: "John Snow" <jsnow@redhat.com>,
"Peter Maydell" <peter.maydell@linaro.org>,
"Daniel P. Berrangé" <berrange@redhat.com>,
qemu-devel <qemu-devel@nongnu.org>
Subject: Re: proposal: deprecate -readconfig/-writeconfig
Date: Fri, 15 May 2020 07:54:27 +0200 [thread overview]
Message-ID: <877dxdspyk.fsf@dusky.pond.sub.org> (raw)
In-Reply-To: <1287b3b8-9fd0-04d5-1dd2-66b695dace5d@redhat.com> (Paolo Bonzini's message of "Thu, 14 May 2020 14:37:34 +0200")
Paolo Bonzini <pbonzini@redhat.com> 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.
next prev parent reply other threads:[~2020-05-15 5:55 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-14 8:09 proposal: deprecate -readconfig/-writeconfig Paolo Bonzini
2020-05-14 8:54 ` Gerd Hoffmann
2020-05-15 5:31 ` Markus Armbruster
2020-05-14 8:56 ` Daniel P. Berrangé
2020-05-14 12:37 ` Paolo Bonzini
2020-05-15 5:54 ` Markus Armbruster [this message]
2020-05-15 10:19 ` Paolo Bonzini
2020-05-14 14:40 ` John Snow
2020-05-14 15:34 ` Daniel P. Berrangé
2020-05-14 15:51 ` Paolo Bonzini
2020-05-14 15:55 ` Daniel P. Berrangé
2020-05-15 5:44 ` Markus Armbruster
2020-05-15 5:51 ` Markus Armbruster
2020-05-15 9:06 ` Gerd Hoffmann
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=877dxdspyk.fsf@dusky.pond.sub.org \
--to=armbru@redhat.com \
--cc=berrange@redhat.com \
--cc=jsnow@redhat.com \
--cc=pbonzini@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.