Message ID | 20180508233659.13973-1-jsnow@redhat.com (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
On 05/08/2018 06:36 PM, John Snow wrote: > When we've reached the concluded state, we need to expose the error > state if applicable. Add the new field. > > This should be sufficient for determining if a job completed > successfully or not after concluding; if we want to discriminate > based on how it failed more mechanically, we can always add an > explicit return code enumeration later. > > I didn't bother to make it only show up if we are in the concluded > state; I don't think it's necessary. > > Signed-off-by: John Snow <jsnow@redhat.com> > --- > blockjob.c | 2 ++ > qapi/block-core.json | 6 +++++- > 2 files changed, 7 insertions(+), 1 deletion(-) > > +++ b/qapi/block-core.json > @@ -1172,6 +1172,9 @@ > # @auto-dismiss: Job will dismiss itself when CONCLUDED, moving to the NULL > # state and disappearing from the query list. (since 2.12) > # > +# @error: Error information if the job did not complete successfully. > +# Not set if the job completed successfully. (since 2.12.1) > +# > # Since: 1.1 > ## > { 'struct': 'BlockJobInfo', > @@ -1179,7 +1182,8 @@ > 'offset': 'int', 'busy': 'bool', 'paused': 'bool', 'speed': 'int', > 'io-status': 'BlockDeviceIoStatus', 'ready': 'bool', > 'status': 'BlockJobStatus', > - 'auto-finalize': 'bool', 'auto-dismiss': 'bool' } } > + 'auto-finalize': 'bool', 'auto-dismiss': 'bool', > + '*error': 'str' } } Yep, definitely material for the stable branch. Reviewed-by: Eric Blake <eblake@redhat.com>
On Wed 09 May 2018 01:36:59 AM CEST, John Snow wrote: > When we've reached the concluded state, we need to expose the error > state if applicable. Add the new field. > > This should be sufficient for determining if a job completed > successfully or not after concluding; if we want to discriminate > based on how it failed more mechanically, we can always add an > explicit return code enumeration later. > > I didn't bother to make it only show up if we are in the concluded > state; I don't think it's necessary. > > Signed-off-by: John Snow <jsnow@redhat.com> Reviewed-by: Alberto Garcia <berto@igalia.com> Berto
Am 09.05.2018 um 01:36 hat John Snow geschrieben: > When we've reached the concluded state, we need to expose the error > state if applicable. Add the new field. > > This should be sufficient for determining if a job completed > successfully or not after concluding; if we want to discriminate > based on how it failed more mechanically, we can always add an > explicit return code enumeration later. > > I didn't bother to make it only show up if we are in the concluded > state; I don't think it's necessary. > > Signed-off-by: John Snow <jsnow@redhat.com> Thanks, applied to the block branch. Kevin
diff --git a/blockjob.c b/blockjob.c index 27f957e571..4de48166b2 100644 --- a/blockjob.c +++ b/blockjob.c @@ -831,6 +831,8 @@ BlockJobInfo *block_job_query(BlockJob *job, Error **errp) info->status = job->status; info->auto_finalize = job->auto_finalize; info->auto_dismiss = job->auto_dismiss; + info->has_error = job->ret != 0; + info->error = job->ret ? g_strdup(strerror(-job->ret)) : NULL; return info; } diff --git a/qapi/block-core.json b/qapi/block-core.json index c50517bff3..7da3bea6bc 100644 --- a/qapi/block-core.json +++ b/qapi/block-core.json @@ -1172,6 +1172,9 @@ # @auto-dismiss: Job will dismiss itself when CONCLUDED, moving to the NULL # state and disappearing from the query list. (since 2.12) # +# @error: Error information if the job did not complete successfully. +# Not set if the job completed successfully. (since 2.12.1) +# # Since: 1.1 ## { 'struct': 'BlockJobInfo', @@ -1179,7 +1182,8 @@ 'offset': 'int', 'busy': 'bool', 'paused': 'bool', 'speed': 'int', 'io-status': 'BlockDeviceIoStatus', 'ready': 'bool', 'status': 'BlockJobStatus', - 'auto-finalize': 'bool', 'auto-dismiss': 'bool' } } + 'auto-finalize': 'bool', 'auto-dismiss': 'bool', + '*error': 'str' } } ## # @query-block-jobs:
When we've reached the concluded state, we need to expose the error state if applicable. Add the new field. This should be sufficient for determining if a job completed successfully or not after concluding; if we want to discriminate based on how it failed more mechanically, we can always add an explicit return code enumeration later. I didn't bother to make it only show up if we are in the concluded state; I don't think it's necessary. Signed-off-by: John Snow <jsnow@redhat.com> --- blockjob.c | 2 ++ qapi/block-core.json | 6 +++++- 2 files changed, 7 insertions(+), 1 deletion(-)