Re: proposal: deprecate -readconfig/-writeconfig

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

On Thu, May 14, 2020 at 10:40:40AM -0400, John Snow wrote:
> 
> 
> 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.)

Yeah, the key thing is that you really want to be able to provide the
whole initial config in one go as an atomic action. I don't want to
issue 100 individual QMP commands to load each initial device. With
that in mind it doesn't really matter whether you do

  $ qemu -qmp stdio
  (qmp) load-config /some/file.yaml

vs

  $ qemu -qmp stdio -load-config /some/file.yaml

though the latter is probably slightly nicer as it lets you grep
for the VM based on the filename visible in the CLI. 

> > 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.
> 
> 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.

My gut feeling is that we need to do something a bit more adventurous
if we're to get QEMU to move forward in solving the 10+ year old problem
of a formally described, consistent configuration syntax.

Just deprecating & removing -readconfig is just one small mole hill out
of 100 so doesn't move things along much on its own.


I tend to think we'd be better served by focusing on introducing a new set
of binaries,  qemu-vm-$TARGET, which exclusively use a new config syntax,
free of any legacy baggage present in qemu-system-$TARGET.

Work on qemu-vm-$TARGET will involve refactoring, and that will certainly
risk causing bugs in qemu-system-$TARGET. The premise though is that this
risk is lower, than if we tried to retrofit a new config syuntax directly
into qemu-system-$TARGET.

In particular I think it is basically impossible to do any meaningful
changes in the main() method of softmmu/vl.c, due to the fragile ordering
for creation of various different devices/backends, and its interaction
with the argv parsing. By using a new qemu-vm-$TARGET we can have a new
softmmu/vm.c, instead of vl.c. We'll still likely need to modify parts of
vl.c to use new/changed API calls, but that's less distruptive, as we
can leave the crazy logic for ordering of device creation untouched.


In the past we've been fairly cautious of any change which might risk
back compat problems in qemu-system-$TARGET. I think we can say we're not
going to gratuitously break qemu-system-$TARGET, but at the same time we
are not going to make heroic efforts at (unachievable) perfection.

IOW, accept that we'll probably cause regressions in some edge cases in
qemu-system-$TARGET. We'll make reasonable effort to fix them if they
are reported, but we're willing to accept the risk of disruption in the
short term, in order to get to a better long term solution.

Depending on how much of a burden it is to keep qemu-system-$TARGET around
long term, it could exist forever without any new feature work on its CLI;
Or it could be turned into a shim around qemu-vm-$TARGET; Or it could
be deprecated over a prolonged period (as opposed to the usual 2 release
minimum).

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 :|