From: "Daniel P. Berrangé" <berrange@redhat.com>
To: John Snow <jsnow@redhat.com>
Cc: Damien Hedde <damien.hedde@greensocs.com>,
Eduardo Habkost <eduardo@habkost.net>,
qemu-devel <qemu-devel@nongnu.org>,
Cleber Rosa <crosa@redhat.com>
Subject: Re: [PATCH 4/5] python: qmp_shell: add -e/--exit-on-error option
Date: Wed, 23 Feb 2022 15:27:11 +0000 [thread overview]
Message-ID: <YhZST1fCU54OgoP2@redhat.com> (raw)
In-Reply-To: <CAFn=p-ZErejiw7mn_kN6c+57ya4OgS3ANpUa=BtS3Be=vcSOvg@mail.gmail.com>
On Wed, Feb 23, 2022 at 10:22:11AM -0500, John Snow wrote:
> On Mon, Feb 21, 2022 at 10:55 AM Damien Hedde
> <damien.hedde@greensocs.com> wrote:
> >
> > This option makes qmp_shell exit (with error code 1)
> > as soon as one of the following error occurs:
> > + command parsing error
> > + disconnection
> > + command failure (response is an error)
> >
> > _execute_cmd() method now returns None or the response
> > so that read_exec_command() can do the last check.
> >
> > This is meant to be used in combination with an input file
> > redirection. It allows to store a list of commands
> > into a file and try to run them by qmp_shell and easily
> > see if it failed or not.
> >
> > Signed-off-by: Damien Hedde <damien.hedde@greensocs.com>
>
> Based on this patch, it looks like you really want something
> scriptable, so I think the qemu-send idea that Dan has suggested might
> be the best way to go. Are you still hoping to use the interactive
> "short" QMP command format? That might be a bad idea, given how flaky
> the parsing is -- and how we don't actually have a published standard
> for that format. We've *never* liked the bad parsing here, so I have a
> reluctance to use it in more places.
>
> I'm having the naive idea that a script file could be as simple as a
> list of QMP commands to send:
>
> [
> {"execute": "block-dirty-bitmap-add", "arguments": { ... }},
> ...
> ]
I'd really recommend against creating a new format for the script
file, especially one needing opening & closing [] like this, as
that isn't so amenable to dynamic usage/creation. ie you can't
just append an extcra command to an existing file.
IMHO, the "file" format should be identical to the result of
capturing the socket data off the wire. ie just a concatenation
of QMP commands, with no extra wrapping / change in format.
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 :|
next prev parent reply other threads:[~2022-02-23 15:28 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-21 15:55 [PATCH 0/5] qmp-shell modifications for non-interactive use Damien Hedde
2022-02-21 15:55 ` [PATCH 1/5] python: qmp_shell: don't prompt when stdin is non-interactive Damien Hedde
2022-02-21 15:55 ` [PATCH 2/5] python: qmp_shell: refactor the parsing error handling Damien Hedde
2022-02-21 15:55 ` [PATCH 3/5] python: qmp_shell: refactor disconnection handling Damien Hedde
2022-02-21 15:55 ` [PATCH 4/5] python: qmp_shell: add -e/--exit-on-error option Damien Hedde
2022-02-23 15:22 ` John Snow
2022-02-23 15:27 ` Daniel P. Berrangé [this message]
2022-02-23 15:41 ` John Snow
2022-02-23 15:44 ` Daniel P. Berrangé
2022-02-23 16:18 ` John Snow
2022-02-23 17:09 ` Damien Hedde
2022-02-23 18:20 ` John Snow
2022-02-24 11:20 ` Damien Hedde
2022-02-23 17:50 ` Daniel P. Berrangé
2022-02-23 16:43 ` Damien Hedde
2022-02-23 16:46 ` Damien Hedde
2022-02-21 15:55 ` [PATCH 5/5] python: qmp_shell: handle comment lines and escaped eol Damien Hedde
2022-02-22 6:10 ` [PATCH 0/5] qmp-shell modifications for non-interactive use Markus Armbruster
2022-02-22 7:57 ` Damien Hedde
2022-02-22 9:21 ` Daniel P. Berrangé
2022-02-22 9:38 ` Damien Hedde
2022-02-22 10:31 ` Daniel P. Berrangé
2022-02-23 9:57 ` Damien Hedde
2022-02-23 11:13 ` Daniel P. Berrangé
2022-02-23 15:01 ` John Snow
2022-02-23 15:08 ` Daniel P. Berrangé
2022-02-22 9:52 ` Markus Armbruster
2022-02-25 20:40 ` John Snow
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=YhZST1fCU54OgoP2@redhat.com \
--to=berrange@redhat.com \
--cc=crosa@redhat.com \
--cc=damien.hedde@greensocs.com \
--cc=eduardo@habkost.net \
--cc=jsnow@redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).