Skip to contentSkip to conversation

blockjob: expose error string via query

PATCH Applied John Snow 4 participants 4 messages May 8, 2018 – May 9, 2018

lore
Share & tools
lore

John Snow

author
#0 lore raw

PATCH 1/1 blockjob: expose error string via query

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 <[email protected]>
---
 blockjob.c           | 2 ++
 qapi/block-core.json | 6 +++++-
 2 files changed, 7 insertions(+), 1 deletion(-)
blockjob.c +2 -0
index 27f957e571..4de48166b2 100644
@@ -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;
 }
qapi/block-core.json +5 -1
index c50517bff3..7da3bea6bc 100644
@@ -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:
Signature · 1 line
2.14.3
Reviewed-by on v1 1/1
#1 lore raw
Quoted 30 lines · John Snow

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 <[email protected]>
---
  blockjob.c           | 2 ++
  qapi/block-core.json | 6 +++++-
  2 files changed, 7 insertions(+), 1 deletion(-)

+++ b/qapi/block-core.json

qapi/block-core.json +3 -0
@@ -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',

qapi/block-core.json line 1186

Quoted 6 lines
qapi/block-core.json +2 -1
@@ -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 <[email protected]>
Signature · 3 lines
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org
Reviewed-by on v1 1/1
#2 lore raw
In reply to John Snow
Quoted 8 lines · John Snow

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.

Quoted 4 lines

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 <[email protected]>
Reviewed-by Alberto Garcia <[email protected]>

Berto

Applied
#3 lore raw
In reply to John Snow

Am 09.05.2018 um 01:36 hat John Snow geschrieben:

Quoted 8 lines

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.

Quoted 4 lines

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 <[email protected]>

Thanks, applied to the block branch.

Kevin