All of lore.kernel.org
 help / color / mirror / Atom feed
From: John Snow <jsnow@redhat.com>
To: Damien Hedde <damien.hedde@greensocs.com>
Cc: Markus Armbruster <armbru@redhat.com>,
	Beraldo Leal <bleal@redhat.com>,
	Daniel Berrange <berrange@redhat.com>,
	qemu-devel <qemu-devel@nongnu.org>,
	Cleber Rosa <crosa@redhat.com>
Subject: Re: [RFC PATCH] python: add qmp-send program to send raw qmp commands to qemu
Date: Tue, 5 Apr 2022 14:08:11 -0400	[thread overview]
Message-ID: <CAFn=p-Y=sTkeMDiht-TCrQKq8WOvbayXjSKiitJkVqUGL6MQNw@mail.gmail.com> (raw)
In-Reply-To: <3d52da6c-124d-4de6-432d-be9e0bb16dfe@greensocs.com>

[-- Attachment #1: Type: text/plain, Size: 4043 bytes --]

On Tue, Apr 5, 2022, 5:03 AM Damien Hedde <damien.hedde@greensocs.com>
wrote:

>
>
> On 4/4/22 22:34, John Snow wrote:
> > On Wed, Mar 16, 2022 at 5:55 AM Damien Hedde <damien.hedde@greensocs.com>
> wrote:
> >>
> >> It takes an input file containing raw qmp commands (concatenated json
> >> dicts) and send all commands one by one to a qmp server. When one
> >> command fails, it exits.
> >>
> >> As a convenience, it can also wrap the qemu process to avoid having
> >> to start qemu in background. When wrapping qemu, the program returns
> >> only when the qemu process terminates.
> >>
> >> Signed-off-by: Damien Hedde <damien.hedde@greensocs.com>
> >> ---
> >>
> >> Hi all,
> >>
> >> Following our discussion, I've started this. What do you think ?
> >>
> >> I tried to follow Daniel's qmp-shell-wrap. I think it is
> >> better to have similar options (eg: logging). There is also room
> >> for factorizing code if we want to keep them aligned and ease
> >> maintenance.
> >>
> >> There are still some pylint issues (too many branches in main and it
> >> does not like my context manager if else line). But it's kind of a
> >> mess to fix theses so I think it's enough for a first version.
> >
> > Yeah, don't worry about these. You can just tell pylint to shut up
> > while you prototype. Sometimes it's just not worth spending more time
> > on a more beautiful factoring. Oh well.
> >
> >>
> >> I name that qmp-send as Daniel proposed, maybe qmp-test matches better
> >> what I'm doing there ?
> >>
> >
> > I think I agree with Dan's response.
> >
> >> Thanks,
> >> Damien
> >> ---
> >>   python/qemu/aqmp/qmp_send.py | 229 +++++++++++++++++++++++++++++++++++
> >
> > I recommend putting this in qemu/util/qmp_send.py instead.
> >
> > I'm in the process of pulling out the AQMP lib and hosting it
> > separately. Scripts like this I think should stay in the QEMU tree, so
> > moving it to util instead is probably best. Otherwise, I'll *really*
> > have to commit to the syntax, and that's probably a bigger hurdle than
> > you want to deal with.
>
> If it stays in QEMU tree, what licensing should I use ? LGPL does not
> hurt, no ?
>

Whichever you please. GPLv2+ would be convenient and harmonizes well with
other tools. LGPL is only something I started doing so that the "qemu.qmp"
package would be LGPL. Licensing the tools as LGPL was just a sin of
convenience so I could claim a single license for the whole wheel/egg/tgz.

(I didn't want to make separate qmp and qmp-tools packages.)

Go with what you feel is best.


> >
> >>   scripts/qmp/qmp-send         |  11 ++
> >>   2 files changed, 240 insertions(+)
> >>   create mode 100644 python/qemu/aqmp/qmp_send.py
> >>   create mode 100755 scripts/qmp/qmp-send
> >>
> >> diff --git a/python/qemu/aqmp/qmp_send.py b/python/qemu/aqmp/qmp_send.py
> >> new file mode 100644
> >> index 0000000000..cbca1d0205
> >> --- /dev/null
> >> +++ b/python/qemu/aqmp/qmp_send.py
> >
> > Seems broadly fine to me, but I didn't review closely this time. If it
> > works for you, it works for me.
> >
> > As for making QEMU hang: there's a few things you could do, take a
> > look at iotests and see how they handle timeout blocks in synchronous
> > code -- iotests.py line 696 or so, "class Timeout". When writing async
> > code, you can also do stuff like this:
> >
> > async def foo():
> >      await asyncio.wait_for(qmp.execute("some-command", args_etc),
> timeout=30)
> >
> > See https://docs.python.org/3/library/asyncio-task.html#asyncio.wait_for
> >
> > --js
> >
>
> Thanks for the tip,
> --
> Damien
>

Oh, and one more. the legacy.py bindings for AQMP also support a
configurable timeout that applies to most API calls by default.

see https://gitlab.com/jsnow/qemu.qmp/-/blob/main/qemu/qmp/legacy.py#L285

(Branch still in limbo here, but it should still be close to the same in
qemu.git)

I believe this is used by iotests.py when it sets up its machine.py
subclass ("VM", iirc) so that most qmp invocations in iotests have a
default timeout and won't hang tests indefinitely.

--js

>

[-- Attachment #2: Type: text/html, Size: 6186 bytes --]

  parent reply	other threads:[~2022-04-05 18:09 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-16  9:54 [RFC PATCH] python: add qmp-send program to send raw qmp commands to qemu Damien Hedde
2022-03-16 10:24 ` Daniel P. Berrangé
2022-03-16 14:16   ` Damien Hedde
2022-04-05  5:41   ` Markus Armbruster
2022-04-05 12:45     ` Damien Hedde
2022-04-19 17:18       ` Daniel P. Berrangé
2022-04-20  6:28         ` Markus Armbruster
2022-04-04 20:34 ` John Snow
2022-04-05  9:02   ` Damien Hedde
2022-04-05  9:45     ` Markus Armbruster
2022-04-05 18:08     ` John Snow [this message]
2022-04-06  5:18       ` Markus Armbruster
2022-05-25 16:06 ` Daniel P. Berrangé
2022-05-30  7:12   ` Damien Hedde

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAFn=p-Y=sTkeMDiht-TCrQKq8WOvbayXjSKiitJkVqUGL6MQNw@mail.gmail.com' \
    --to=jsnow@redhat.com \
    --cc=armbru@redhat.com \
    --cc=berrange@redhat.com \
    --cc=bleal@redhat.com \
    --cc=crosa@redhat.com \
    --cc=damien.hedde@greensocs.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.