From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Damien Hedde <damien.hedde@greensocs.com>
Cc: Eduardo Habkost <eduardo@habkost.net>,
Cleber Rosa <crosa@redhat.com>, John Snow <jsnow@redhat.com>,
Markus Armbruster <armbru@redhat.com>,
qemu-devel@nongnu.org
Subject: Re: [PATCH 0/5] qmp-shell modifications for non-interactive use
Date: Tue, 22 Feb 2022 10:31:56 +0000 [thread overview]
Message-ID: <YhS7nE+6++YN4exZ@redhat.com> (raw)
In-Reply-To: <c3fb1a44-29ac-00a0-47f4-7f152977f4a5@greensocs.com>
On Tue, Feb 22, 2022 at 10:38:09AM +0100, Damien Hedde wrote:
>
>
> On 2/22/22 10:21, Daniel P. Berrangé wrote:
> > On Tue, Feb 22, 2022 at 08:57:03AM +0100, Damien Hedde wrote:
> > >
> > >
> > > On 2/22/22 07:10, Markus Armbruster wrote:
> > > > Damien Hedde <damien.hedde@greensocs.com> writes:
> > > >
> > > > > Hi,
> > > > >
> > > > > The main idea of this series is to be a bit more user-friendly when
> > > > > using qmp-shell in a non-interactive way: with an input redirection
> > > > > from a file containing a list of commands.
> > > > >
> > > > > I'm working on dynamic qapi config of a qemu machine, this would
> > > > > be very useful to provide and reproduce small examples.
> > > >
> > > > Why not use plain QMP for that?
> > > >
> > > > [...]
> > > >
> > > What do you mean by plain QMP ?
> >
> > Directly connect to the socket and send the QMP JSON commands you have.
> >
> > Essentially qmp-shell is designed for adhoc interactive human usage.
> > For automated / scripted, non-interactive usage, it is expected that
> > QMP is simple enough that tools just directly connect to the QMP
> > socket instead of using a wrapper layer.
> >
> > What is the reason you want to use qmp-shell for this instead of
> > directly using the socket from your scripts ?
> >
> > Regards,
> > Daniel
>
> We have such scripts that interface with QMP directly for our own use.
>
> Here I just wanted to propose a simple way to just send a
> bunch of commands from a source file and stop if something unexpected
> happens.
> Only goal is to be able to share a file on the ml and allow people to
> reproduce easily.
> We can already redirect the input, but it is almost impossible to see
> if something failed.
Yes, I see what you mean. So the problem with using 'socat' or similar
is that we fill the input with commands and response appear asynchronously,
so we can't match them up easily. This is actually a problem seen in the
block I/O tests which just send QMP stuff in a batch.
While you could do this by invoking socat once for each command, that
gets silly with the repeated QMP handshake for each command.
The thing about using qmp-shell is that it does a bunch of extra stuff
targetted at humans on top, and history tells us it isn't a good idea
to mix stuff for humans and machines in the same tool/interface.
How about instead creating a separate 'qmp-send' command that is not
much more than a "QMP-aware socat". By which I mean, it just reads
raw QMP commands from stdin, sends each one to the server, but
crucially waits for a reply after sending each, and stops on first
error reponse.
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-22 10:35 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é
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é [this message]
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=YhS7nE+6++YN4exZ@redhat.com \
--to=berrange@redhat.com \
--cc=armbru@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).