On Thu, Dec 09, 2021 at 09:01:24PM +0100, Mark Burton wrote: > I’ll take the liberty to cut one part (I agree with much of what you say > elsewhere) > > > On 9 Dec 2021, at 20:11, Daniel P. Berrangé <berra...@redhat.com> wrote: > > > > As illustrated earlier, I'd really like us to consider being a bit > > more adventurous on the CLI side. I'm convinced that a CLI for > > directly configurable hardware is doomed to be horrible no matter > > what, if you try to directly expose all QAPI configuration > > flexibilty. Whether key/value, JSON, whatever, it will become > > unmanagable on the CLI because VM hardware config is inherantly > > complicated. > > > > I absolutely agree, but reach a slightly different conclusion > > > Thus my though that config files or QMP should be the only two > > places where the full power of QAPI config is exposed. Use CLI > > as just a way to interact with config files in a simple way > > with templates. > > I would countenance that we choose only one place to ‘support’ an interface. > Either “Yet Another Hardware Configuration Language” or QAPI. Rather than > re-inventing that wheel I would simply suggest that we leave that to the > relevant ‘user’ community (libvirt, whatever), who have specific requirements > and/or existing solutions. Leaving QEMU itself to focus on improving QAPI > (and migrating the CLI).
Yes, indeed, the logical extension of my idea is that the 'simple' CLI + templating thing doesn't atually have to be in the main QEMU binary at all. We could in fact ship a bare '/usr/bin/qemu' which does the config file templating and spawns whatever full QEMU binary (/usr/bin/qemu-system-blah) does the real VM. The key is just that we have something simple for users, who don't want a full mgmt layer and like the historical QEMU simple configs. 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 :|