Thank you everyone who joined the call. The meeting notes are below.
Stefan
---
*KVM Community Call - Tue Oct 6th
*Topic: QEMU CLI QAPI conversion
* John Snow's summary of command-line options:
https://docs.google.com/spreadsheets/d/1OJvzDwLpo2XsGytNp9Pr-vYIrb0pWrFKBNPtOyH80ew/edit?usp=sharing
* What is the first milestone?
* Is it QemuOpts for everything? Straight to QAPI? something else?
* Markus: The goal is to represent the configuration interface
in QAPI types
* Don't parse QemuOpts, go straight to QAPI
* How do we distribute this work to multiple engineers?
* Examples:
* --blockdev API is used on the command-line
* --display
* qemu-storage-daemon command-line is largely QAPI-fied
* Alex Bennee:
* We should have a gold-standard reference with documentation
if we are to expect maintainers to convert their own flags
* -> John Snow will work on this document
* Do we have good examples of turning QemuOpts to QAPI?
* 53 of our 93 CLI flags that take arguments are QemuOpts, so
this is a major component
* Kevin: -monitor for the Qemu Storage Daemon, recently
* John Snow: Final milestone might be an automated QAPI-based CLI
parser, but only once QAPI types have been defined
* Does command-line order matter?
* Two options: allow any order OR left-to-right ordering
* Andrea Bolognani: Most users expect left-to-right ordering,
why allow any order?
* Eduardo Habkost: Can we enforce left-to-right ordering or do
we need to follow the deprecation process?
* Daniel Berrange: Solve compability by introducing new
binaries without the burden of backwards compability
* Unclear whether we will reach consensus on this call
about this. Maybe raise it on qemu-devel. [stefanha]
* Philippe: Easy command-line options (-drive) and
managent-friendly options (-blockdev) could be offered by different
binaries
* Daniel Berrange: Focussing on one new binary is more
achievable
* Board defaults, configuration file options
* How to set properties on existing objects (e.g. board defaults)?
* Andrea Bolognani: Perhaps represent the board defaults as a
list of ordered options, append user-provided options, and *only then*
create the object?
* Currently the boards create QOM objects directly, they
don't involve QAPI
* Stefan: How do QOM objects/properties fit into QAPI
CLI/configuration parsing?
* QAPI objects are processed by functions that will create
QOM objects
* Markus: -global is broken
* Eduardo: Long-term goal to describe QOM properties in QAPI
* Daniel Berrange: eliminate QOM boilerplate by describing
object properties in QAPI
* Markus: It's hard to use QAPI because QOM properties are
dynamic and can change at runtime
* Next steps
* John Snow and Markus will work on reference documentation
Bluejeans Chat Log
[ 9:02] Stefan Hajnoczi: https://etherpad.opendev.org/p/QEMUCLI
[ 9:05] John Ferlan: @stefan - there are some people in a different room....
[ 9:08] Daniel Berrange: if you're not talking please mute
[ 9:24] Alex Bennée: I ran into this ordering stuff w.r.t
semihosting and chardevs so knowing how to properly order things in
the "new world" would be useful
[ 9:33] Phil: YAML &anchor symbol is helpful to use a definition
from a previous layer
[ 9:34] Mdasoh: It makes sense to have ordered options when you're
talking about putting objects within objects; at the same time it
doesn't make so much sense to order them when you're talking about
running them all through a BNF parser (flex+yacc?) for user-friendly
configuration. So of course there would be two layers, and you would
translate the unordered options into a set of encapsulating or ordered
options.
[ 9:49] Andrea Bolognani: It Will Be Totally Different This Time™
[ 9:50] John Snow: ^ that's partly why I wanted to discuss this,
to set concrete goals and to be able to measure progress
[ 9:51] Alex Bennée: I'm afraid I have to drop off for the school
run - look forward to reading the reference docs ;-)
[ 9:51] John Snow: ^ ty Alex
[10:00] Stefan Hajnoczi: I need to drop now. I'll send the meeting
notes to the mailing list. Bye!
[10:00] Kevin: Same for me
[10:00] John Snow: OK!
