On Mon, Sep 18, 2023 at 04:54:22AM -0600, Daniel Xu wrote: > Currently, commands run through guest-exec are "silent" until they > finish running. This is fine for short lived commands. But for commands > that take a while, this is a bad user experience. > > Usually long running programs know that they will run for a while. To > improve user experience, they will typically print some kind of status > to output at a regular interval. So that the user knows that their > command isn't just hanging. > > This commit adds support for an optional stream-output parameter to > guest-exec. This causes subsequent calls to guest-exec-status to return > all buffered output. This allows downstream applications to be able to > relay "status" to the end user. > > If stream-output is requested, it is up to the guest-exec-status caller > to keep track of the last seen output position and slice the returned > output appropriately. This is fairly trivial for a client to do. And it > is a more reliable design than having QGA internally keep track of > position -- for the cases that the caller "loses" a response.
I can understand why you want this incremental output facility, but at the same time I wonder where we draw the line for QGA with users needing a real shell session instead. When there is a long lived command, then IMHO it is also likely that there will be a need to kill the background running command too. We quickly end up re-inventing a shell in QGA if we go down this route. With 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 :|
