From: Markus Armbruster <armbru@redhat.com>
To: Daniel Xu <dxu@dxuuu.xyz>
Cc: kkostiuk@redhat.com, michael.roth@amd.com, berrange@redhat.com,
qemu-devel@nongnu.org, hmodi@aviatrix.com
Subject: Re: [PATCH 2/3] qga: Add optional stream-output argument to guest-exec
Date: Mon, 18 Sep 2023 17:05:03 +0200 [thread overview]
Message-ID: <87il87bjz4.fsf@pond.sub.org> (raw)
In-Reply-To: <604ef5fd5bda8acdb837b5d28ec405e9fb0332a3.1695034158.git.dxu@dxuuu.xyz> (Daniel Xu's message of "Mon, 18 Sep 2023 04:54:22 -0600")
Daniel Xu <dxu@dxuuu.xyz> writes:
> 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.
>
> Signed-off-by: Daniel Xu <dxu@dxuuu.xyz>
> ---
[...]
> diff --git a/qga/qapi-schema.json b/qga/qapi-schema.json
> index b720dd4379..0a76e35082 100644
> --- a/qga/qapi-schema.json
> +++ b/qga/qapi-schema.json
> @@ -1315,13 +1315,18 @@
> # @capture-output: bool flag to enable capture of stdout/stderr of
> # running process. defaults to false.
> #
> +# @stream-output: causes future guest-exec-status calls to always
> +# return current captured output rather than waiting to return
> +# it all when the command exits. defaults to false. (since: 8.2)
So guest-exec-status normally returns no captured output until the
process terminates, right? Its documentation (shown below for
convenience) did not make me expect this!
> +#
> # Returns: PID on success.
> #
> # Since: 2.5
> ##
> { 'command': 'guest-exec',
> 'data': { 'path': 'str', '*arg': ['str'], '*env': ['str'],
> - '*input-data': 'str', '*capture-output': 'GuestExecCaptureOutput' },
> + '*input-data': 'str', '*capture-output': 'GuestExecCaptureOutput',
> + '*stream-output': 'bool' },
> 'returns': 'GuestExec' }
##
# @GuestExecStatus:
#
# @exited: true if process has already terminated.
#
# @exitcode: process exit code if it was normally terminated.
#
# @signal: signal number (linux) or unhandled exception code (windows)
# if the process was abnormally terminated.
#
# @out-data: base64-encoded stdout of the process
#
# @err-data: base64-encoded stderr of the process Note: @out-data and
# @err-data are present only if 'capture-output' was specified for
# 'guest-exec'
#
# @out-truncated: true if stdout was not fully captured due to size
# limitation.
#
# @err-truncated: true if stderr was not fully captured due to size
# limitation.
#
# Since: 2.5
##
{ 'struct': 'GuestExecStatus',
'data': { 'exited': 'bool', '*exitcode': 'int', '*signal': 'int',
'*out-data': 'str', '*err-data': 'str',
'*out-truncated': 'bool', '*err-truncated': 'bool' }}
##
# @guest-exec-status:
#
# Check status of process associated with PID retrieved via
# guest-exec. Reap the process and associated metadata if it has
# exited.
#
# @pid: pid returned from guest-exec
#
# Returns: GuestExecStatus on success.
#
# Since: 2.5
##
{ 'command': 'guest-exec-status',
'data': { 'pid': 'int' },
'returns': 'GuestExecStatus' }
Could you throw in a patch to clarify what exactly is returned while the
process is still running, and what only after it terminated? It should
go first.
next prev parent reply other threads:[~2023-09-18 15:06 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-18 10:54 [PATCH 0/3] qga: Add optional stream-output argument to guest-exec Daniel Xu
2023-09-18 10:54 ` [PATCH 1/3] qga: Fix memory leak when output stream is unused Daniel Xu
2023-09-21 9:55 ` Konstantin Kostiuk
2023-09-18 10:54 ` [PATCH 2/3] qga: Add optional stream-output argument to guest-exec Daniel Xu
2023-09-18 15:05 ` Markus Armbruster [this message]
2023-09-18 16:59 ` Daniel Xu
2023-09-18 15:14 ` Daniel P. Berrangé
2023-09-18 17:17 ` Daniel Xu
2023-09-27 8:43 ` Konstantin Kostiuk
2023-10-01 18:39 ` Daniel Xu
2023-09-18 10:54 ` [PATCH 3/3] qga: test: Add test for guest-exec stream-output Daniel Xu
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=87il87bjz4.fsf@pond.sub.org \
--to=armbru@redhat.com \
--cc=berrange@redhat.com \
--cc=dxu@dxuuu.xyz \
--cc=hmodi@aviatrix.com \
--cc=kkostiuk@redhat.com \
--cc=michael.roth@amd.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.