On Wed, Feb 23, 2022 at 10:01:05AM -0500, John Snow wrote: > On Wed, Feb 23, 2022 at 6:13 AM Daniel P. Berrangé <berra...@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.
My concern is that qmp-shell takes command input in a high level data format. I don't want to see that format turn into something that machines use, which is what is proposed initially here. For this reason I prefer to see a separate qmp-send that solves the automation problems, without introducing a new data format, just directly passing raw QMP messages to/fro. 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 :|
