Re: KVM call for agenda for 2022-01-25

[Markus Armbruster <armbru@redhat.com>]

Juan Quintela <quintela@redhat.com> writes:

> Hi
>
> Please, send any topic that you are interested in covering.
>
> This week we have a continuation of 2 weeks ago call to discuss how to
> enable creation of machines from QMP sooner on the boot.
>
> There was already a call about this 2 weeks ago where we didn't finished
> everything.
> I have been on vacation last week and I haven't been able to send a
> "kind of resume" of the call.
>
> Basically what we need is:
> - being able to create machines sooner that we are today
> - being able to change the devices that are in the boards, in
>   particular, we need to be able to create a board deciding what devices
>   it has and how they are connected without recompiling qemu.
>   This means to launch QMP sooner that we do today.
> - Several options was proposed:
>   - create a new binary that only allows QMP machine creation.
>     and continue having the old command line
>   - create a new binary, and change current HMP/command line to just
>     call this new binary.  This way we make sure that everything can be
>     done through QMP.
>   - stay with only one binary but change it so we can call QMP sooner.
> - There is agreement that we need to be able to call QMP sooner.
> - There is NO agreement about how the best way to proceed:
>   * We don't want this to be a multiyear effort, i.e. we want something
>     that can be used relatively soon (this means that using only one
>     binary can be tricky).
>   * If we start with a new binary that only allows qmp and we wait until
>     everything has been ported to QMP, it can take forever, and during
>     that time we have to maintain two binaries.
>   * Getting a new binary lets us to be more agreessive about what we can
>     remove/change. i.e. easier experimentation.
>   * Management Apps will only use QMP, not the command line, or they
>     even use libvirt and don't care at all about qemu.  So it appears
>     that HMP is only used for developers, so we can be loose about
>     backwards compatibility. I.e. if we allow the same functionality,
>     but the syntax is different, we don't care.
>
> Discussion was longer, but it was difficult to take notes and as I said,
> the only thing that appears that everybody agrees is that we need an
> agreement about what is the plan to go there.
>
> After discussions on the QEMU Summit, we are going to have always open a
> KVM call where you can add topics.
>
>  Call details:
>
> By popular demand, a google calendar public entry with it
>
>   https://www.google.com/calendar/embed?src=dG9iMXRqcXAzN3Y4ZXZwNzRoMHE4a3BqcXNAZ3JvdXAuY2FsZW5kYXIuZ29vZ2xlLmNvbQ
>
> (Let me know if you have any problems with the calendar entry.  I just
> gave up about getting right at the same time CEST, CET, EDT and DST).

https://wiki.qemu.org/Contribute claims the call is at

    $ date -d 'TZ="America/New_York" Tuesday 10:00 am'
    Tue Jan 25 16:00:00 CET 2022

Is that correct?

> If you need phone number details,  contact me privately
>
> Thanks, Juan.