[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH 0/5] qmp-shell modifications for non-interactive use
From: |
Daniel P . Berrangé |
Subject: |
Re: [PATCH 0/5] qmp-shell modifications for non-interactive use |
Date: |
Wed, 23 Feb 2022 11:13:43 +0000 |
User-agent: |
Mutt/2.1.5 (2021-12-30) |
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.
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 :|
- Re: [PATCH 4/5] python: qmp_shell: add -e/--exit-on-error option, (continued)
Re: [PATCH 0/5] qmp-shell modifications for non-interactive use, Markus Armbruster, 2022/02/22
- Re: [PATCH 0/5] qmp-shell modifications for non-interactive use, Damien Hedde, 2022/02/22
- Re: [PATCH 0/5] qmp-shell modifications for non-interactive use, Daniel P . Berrangé, 2022/02/22
- Re: [PATCH 0/5] qmp-shell modifications for non-interactive use, Damien Hedde, 2022/02/22
- Re: [PATCH 0/5] qmp-shell modifications for non-interactive use, Daniel P . Berrangé, 2022/02/22
- Re: [PATCH 0/5] qmp-shell modifications for non-interactive use, Damien Hedde, 2022/02/23
- Re: [PATCH 0/5] qmp-shell modifications for non-interactive use,
Daniel P . Berrangé <=
- Re: [PATCH 0/5] qmp-shell modifications for non-interactive use, John Snow, 2022/02/23
- Re: [PATCH 0/5] qmp-shell modifications for non-interactive use, Daniel P . Berrangé, 2022/02/23
Re: [PATCH 0/5] qmp-shell modifications for non-interactive use, Markus Armbruster, 2022/02/22
Re: [PATCH 0/5] qmp-shell modifications for non-interactive use, John Snow, 2022/02/25