Re: [PATCH 0/5] qmp-shell modifications for non-interactive use

[John Snow]

On Wed, Feb 23, 2022 at 6:13 AM Daniel P. Berrangé <berrange@redhat.com> wrote:
>
> On Wed, Feb 23, 2022 at 10:57:29AM +0100, Damien Hedde wrote:
> >
> >
> > On 2/22/22 11:31, Daniel P. Berrangé wrote:
> > > On Tue, Feb 22, 2022 at 10:38:09AM +0100, Damien Hedde wrote:
> > > >
> > > >
> > > > 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.
> >
> > By 'qmp-send' command, you mean another script in scripts/qmp ?
> > Yes
>
> Yep.
>
> > If we go for another script, I would rather do one with wrap
> > feature (like your series) to start qemu as well.
>
> Sure, that would certainly make sense.  I actually wanted to add
> the wrap feature directly into the existing qmp-shell, but it was
> not viable while maintaining back compat. With a new qmp-send
> command you can easily make "wrap mode" supported from the start.
>

I'm also wary of adding scriptable interfaces to qmp-shell, but I can
see them having some value.

I'm not against the ability to add some kind of "load commands from
file" interactive command to qmp-shell, for instance. (/LOAD or /PLAY
or something?) ... but then we need to worry about what the format of
the file is and how exactly that scripting language works. It's a
design minefield.

I can also see the use in having qmp-shell autoplay a script file at
startup and then resume interactive function (Saves you some typing!),
but that opens the door to people using it as a script in and of
itself and coming to rely on it, which I really would not like to see.
A standalone qemu-send that supports launching QEMU (with args) and
taking a script file from the CLI sounds great, though.

There's still some design questions I have, though: What features do
you need out of the script file? What syntax do you intend to use?
Does it need event waits? How complex do they need to be? I'm fine
with something simple, but I can see cases where we might begin to
want slightly more power out of it. I see good utility for test
reproductions shared on the ML and in bug trackers, though.

--js