Re: QAPI sync meeting

[Marc-André Lureau]

Hi!

On Mon, Sep 27, 2021 at 8:55 PM John Snow <jsnow@redhat.com> wrote:

Hiya,

I'd like to propose that at least the three of us arrange a time to have a meeting where we discuss our plans and ideas for QAPI going forward, including rust, python, and golang extensions to the QAPI generator, what we hope to accomplish with those projects, and so on.

What I am hoping to get out of this for myself is a high-level overview of people's plans for QAPI and to produce some notes on those plans so that I can have a reference that we've all acknowledged as roughly accurate to be able to keep the community's design goals for QAPI in mind as I continue my own development. Ultimately, I'd like some kind of rough draft of a "QAPI roadmap".

I know there was a rust meetup during KVM Forum, but I was unable to attend due to the timing. I'd like to expand the focus a little more broadly to QAPI in general and discuss our "personal" roadmaps, goals, queued work, etc so that we can collaboratively formulate a broader vision of our work.

I'm posting to qemu-devel in case anyone else has an interest in this area and would like to eavesdrop or share opinions, but we should probably come up with an agenda first. So:

Proposed agenda:

Current projects, wishlists, and goals for QAPI:

- Markus (~10 min)

- Marc-Andre (~10 min) (Rust, dbus, etc?)

The QAPI Rust binding RFC series aims to provide the QAPI types to Rust with to/from C translations. This is just one brick allowing QEMU to have some parts written in Rust: all other internal/subsystem binding pieces remain to be done. I don't have other plans for QAPI at this point.

D-Bus (from the early qapi/rust series) was an experiment, showing that QAPI/QMP can be exposed via "serde" with almost no effort. (it could most likely be over other protocols, such as JSON, in full-Rust implementation). We can imagine sharing canonical QAPI IDLs for daemons/helpers written in different languages.

However, the biggest hurdle when binding QAPI to D-Bus or many programming languages (c, python, go and rust foremost) is that it is not a machine/ABI-friendly IDL. QAPI doesn't impose orderdering of fields or arguments, and it is not versioned. I believe this is detrimental, because bindings have to be written and maintained by hand in various languages, with various flavours (some may add abstractions, some may version the schema themself, some may use plain dictionaries everywhere etc). The small flexibility advantage doesn't outweigh the cost. Imho, some of the pains of QAPI/QMP is that it's not so easy to interact with, either from a human point of view (who likes speaking JSON?) or a machine point of view (I don't have good bindings to use from my language of choice). If we provided (and generated) idiomatic client bindings, we would most likely have a few rules to not break them, and end up versionizing the schema (version the commands, version arguments etc, various options are possible). The wire format becomes a detail, and JSON can keep its own flexibility wrt fields ordering etc.

- jsnow (~10 min) (Python, golang, etc)

I am certainly interested to learn your updated plans.

 

Formulating short-term and long-term roadmaps:

- Open discussion, ~30 min
- Collaboratively produce a summary doc (etherpad?) outlining major work to be done, separated into near and long terms

- Upload this summary to the QEMU wiki and mail it back out to qemu-devel

- We probably won't exactly finish this bit, but we can resume on the mailing list afterwards perfectly well.

(Feel free to propose anything different for the meeting, this is just a jumping off point for discussion.)

Proposed time:

- Any weekday after 13:00 UTC. Wednesdays, Thursdays and Fridays work particularly well for me at the moment.

That could work for me.

- bluejeans and google meeting both work well for me. Open to alternatives.

Thanks,

--js