file-posix: Consolidate the locking error message

When hot-plugging a block device fails due to image locking errors,
users won't see the helpful 'Is another process using the image?'
message in QMP because currently the error hint is not carried over
there.

Even though extending QMP to include hint is a conceivably easy task,
Libvirt will need some change to consume that data.

Before that is fully sorted out, let's just do the easy fix by joining
the two lines.

Signed-off-by: Fam Zheng <famz@redhat.com>
---
 block/file-posix.c         | 10 ++--
 tests/qemu-iotests/153.out | 99 +++++++++++++-------------------------
 tests/qemu-iotests/182.out |  3 +-
 3 files changed, 38 insertions(+), 74 deletions(-)

On 06/01/2018 04:18 AM, Fam Zheng wrote:
> When hot-plugging a block device fails due to image locking errors,
> users won't see the helpful 'Is another process using the image?'
> message in QMP because currently the error hint is not carried over
> there.
> 
> Even though extending QMP to include hint is a conceivably easy task,
> Libvirt will need some change to consume that data.
> 
> Before that is fully sorted out, let's just do the easy fix by joining
> the two lines.
> 
> Signed-off-by: Fam Zheng <famz@redhat.com>
> ---
>   block/file-posix.c         | 10 ++--
>   tests/qemu-iotests/153.out | 99 +++++++++++++-------------------------
>   tests/qemu-iotests/182.out |  3 +-
>   3 files changed, 38 insertions(+), 74 deletions(-)
> 
> diff --git a/block/file-posix.c b/block/file-posix.c
> index 5a602cfe37..03776e13b1 100644
> --- a/block/file-posix.c
> +++ b/block/file-posix.c
> @@ -699,11 +699,10 @@ static int raw_check_lock_bytes(BDRVRawState *s,
>               if (ret) {
>                   char *perm_name = bdrv_perm_names(p);
>                   error_setg(errp,
> -                           "Failed to get \"%s\" lock",
> +                           "Failed to get \"%s\" lock. "
> +                           "Is another process using the image?",

Except that this goes against the error message recommendations that 
Markus has tried to remind people of (in general, using a full-stop in 
error_setg() is frowned on).  Markus, do you have any suggestions?

On Fri, Jun 01, 2018 at 05:18:35PM +0800, Fam Zheng wrote:
> When hot-plugging a block device fails due to image locking errors,
> users won't see the helpful 'Is another process using the image?'
> message in QMP because currently the error hint is not carried over
> there.
> 
> Even though extending QMP to include hint is a conceivably easy task,
> Libvirt will need some change to consume that data.
> 
> Before that is fully sorted out, let's just do the easy fix by joining
> the two lines.

There are many places in QEMU which uses error hints and these are all
invisible to libvirt. Arbitrarily picking one hint to remove, while
leaving everything else unfixed is not a very satisfactory approach.

If QEMU passes the hint in QMP, it is trivial for libvirt to be changed
to append the hint when reporting its own error message, so can we just
focus on fixing the root cause instead of special casing file-posix.c


Regards,
Daniel

On Fri, 06/01 13:43, Daniel P. Berrangé wrote:
> On Fri, Jun 01, 2018 at 05:18:35PM +0800, Fam Zheng wrote:
> > When hot-plugging a block device fails due to image locking errors,
> > users won't see the helpful 'Is another process using the image?'
> > message in QMP because currently the error hint is not carried over
> > there.
> > 
> > Even though extending QMP to include hint is a conceivably easy task,
> > Libvirt will need some change to consume that data.
> > 
> > Before that is fully sorted out, let's just do the easy fix by joining
> > the two lines.
> 
> There are many places in QEMU which uses error hints and these are all
> invisible to libvirt. Arbitrarily picking one hint to remove, while
> leaving everything else unfixed is not a very satisfactory approach.
> 
> If QEMU passes the hint in QMP, it is trivial for libvirt to be changed
> to append the hint when reporting its own error message, so can we just
> focus on fixing the root cause instead of special casing file-posix.c

The plan was to work on the QMP change in parallel, while this simple patch can
mitigate the confusion caused by the relatively vague message (the text itself
is going a bit on the cryptic side for people who don't know QEMU internals).

Fam

On Fri, 06/01 07:32, Eric Blake wrote:
> On 06/01/2018 04:18 AM, Fam Zheng wrote:
> > When hot-plugging a block device fails due to image locking errors,
> > users won't see the helpful 'Is another process using the image?'
> > message in QMP because currently the error hint is not carried over
> > there.
> > 
> > Even though extending QMP to include hint is a conceivably easy task,
> > Libvirt will need some change to consume that data.
> > 
> > Before that is fully sorted out, let's just do the easy fix by joining
> > the two lines.
> > 
> > Signed-off-by: Fam Zheng <famz@redhat.com>
> > ---
> >   block/file-posix.c         | 10 ++--
> >   tests/qemu-iotests/153.out | 99 +++++++++++++-------------------------
> >   tests/qemu-iotests/182.out |  3 +-
> >   3 files changed, 38 insertions(+), 74 deletions(-)
> > 
> > diff --git a/block/file-posix.c b/block/file-posix.c
> > index 5a602cfe37..03776e13b1 100644
> > --- a/block/file-posix.c
> > +++ b/block/file-posix.c
> > @@ -699,11 +699,10 @@ static int raw_check_lock_bytes(BDRVRawState *s,
> >               if (ret) {
> >                   char *perm_name = bdrv_perm_names(p);
> >                   error_setg(errp,
> > -                           "Failed to get \"%s\" lock",
> > +                           "Failed to get \"%s\" lock. "
> > +                           "Is another process using the image?",
> 
> Except that this goes against the error message recommendations that Markus
> has tried to remind people of (in general, using a full-stop in error_setg()
> is frowned on).  Markus, do you have any suggestions?

OK, now I remember what Markus suggested was a paranthesis around the second
sentence instead of following a full-stop. So it will look like:

"Failed to get shared \"%s\" lock (is another process using the image?)"

Is that an acceptable form?

Fam

On Fri, Jun 01, 2018 at 09:33:59PM +0800, Fam Zheng wrote:
> On Fri, 06/01 13:43, Daniel P. Berrangé wrote:
> > On Fri, Jun 01, 2018 at 05:18:35PM +0800, Fam Zheng wrote:
> > > When hot-plugging a block device fails due to image locking errors,
> > > users won't see the helpful 'Is another process using the image?'
> > > message in QMP because currently the error hint is not carried over
> > > there.
> > > 
> > > Even though extending QMP to include hint is a conceivably easy task,
> > > Libvirt will need some change to consume that data.
> > > 
> > > Before that is fully sorted out, let's just do the easy fix by joining
> > > the two lines.
> > 
> > There are many places in QEMU which uses error hints and these are all
> > invisible to libvirt. Arbitrarily picking one hint to remove, while
> > leaving everything else unfixed is not a very satisfactory approach.
> > 
> > If QEMU passes the hint in QMP, it is trivial for libvirt to be changed
> > to append the hint when reporting its own error message, so can we just
> > focus on fixing the root cause instead of special casing file-posix.c
> 
> The plan was to work on the QMP change in parallel, while this simple patch can
> mitigate the confusion caused by the relatively vague message (the text itself
> is going a bit on the cryptic side for people who don't know QEMU internals).

I still don't think that it makes sense to remove the use of hints in the
block layer.

If we don't care about improved error messages for existing libvirt
versions, we can just add a 'hint' field in QMP and let new libvirt
use that:

diff --git a/qapi/qmp-dispatch.c b/qapi/qmp-dispatch.c
index 935f9e159c..82eb823f1f 100644
--- a/qapi/qmp-dispatch.c
+++ b/qapi/qmp-dispatch.c
@@ -132,9 +132,15 @@ static QObject *do_qmp_dispatch(QmpCommandList *cmds, QObject *request,
 
 QObject *qmp_build_error_object(Error *err)
 {
-    return qobject_from_jsonf("{ 'class': %s, 'desc': %s }",
-                              QapiErrorClass_str(error_get_class(err)),
-                              error_get_pretty(err));
+    const char *hint = error_get_hint(err);
+    if (hint)
+        return qobject_from_jsonf("{ 'class': %s, 'desc': %s, 'hint': %s }",
+                                  QapiErrorClass_str(error_get_class(err)),
+                                  error_get_pretty(err), hint);
+    else
+        return qobject_from_jsonf("{ 'class': %s, 'desc': %s }",
+                                  QapiErrorClass_str(error_get_class(err)),
+                                  error_get_pretty(err));
 }
 
 /*


there's no error_get_hint method right now, but its impl is essentially
the same as error_get_pretty.


If, however, we want to get better error messages for existing libvirt,
then, we should do:

diff --git a/qapi/qmp-dispatch.c b/qapi/qmp-dispatch.c
index 935f9e159c..bf6f92375a 100644
--- a/qapi/qmp-dispatch.c
+++ b/qapi/qmp-dispatch.c
@@ -132,9 +132,18 @@ static QObject *do_qmp_dispatch(QmpCommandList *cmds, QObject *request,
 
 QObject *qmp_build_error_object(Error *err)
 {
-    return qobject_from_jsonf("{ 'class': %s, 'desc': %s }",
-                              QapiErrorClass_str(error_get_class(err)),
-                              error_get_pretty(err));
+    const char *hint = error_get_hint(err);
+    const char *msg;
+    if (hint) {
+        msg = g_strdup_printf("%s: %s", error_get_pretty(), hint);
+    } else {
+        msg = g_strdup(error_get_pretty());
+    }
+    QObject *ret = qobject_from_jsonf("{ 'class': %s, 'desc': %s }",
+                                      QapiErrorClass_str(error_get_class(err)),
+                                      msg);
+    g_free(msg);
+    return ret;
 }
 
 /*

Personally I'd just go for the first case and only care about new libvirts.

Regards,
Daniel

On Fri, 06/01 15:00, Daniel P. Berrangé wrote:
> On Fri, Jun 01, 2018 at 09:33:59PM +0800, Fam Zheng wrote:
> > On Fri, 06/01 13:43, Daniel P. Berrangé wrote:
> > > On Fri, Jun 01, 2018 at 05:18:35PM +0800, Fam Zheng wrote:
> > > > When hot-plugging a block device fails due to image locking errors,
> > > > users won't see the helpful 'Is another process using the image?'
> > > > message in QMP because currently the error hint is not carried over
> > > > there.
> > > > 
> > > > Even though extending QMP to include hint is a conceivably easy task,
> > > > Libvirt will need some change to consume that data.
> > > > 
> > > > Before that is fully sorted out, let's just do the easy fix by joining
> > > > the two lines.
> > > 
> > > There are many places in QEMU which uses error hints and these are all
> > > invisible to libvirt. Arbitrarily picking one hint to remove, while
> > > leaving everything else unfixed is not a very satisfactory approach.
> > > 
> > > If QEMU passes the hint in QMP, it is trivial for libvirt to be changed
> > > to append the hint when reporting its own error message, so can we just
> > > focus on fixing the root cause instead of special casing file-posix.c
> > 
> > The plan was to work on the QMP change in parallel, while this simple patch can
> > mitigate the confusion caused by the relatively vague message (the text itself
> > is going a bit on the cryptic side for people who don't know QEMU internals).
> 
> I still don't think that it makes sense to remove the use of hints in the
> block layer.

I have no inclination to changing any other hints in the block layer. See
below..

> 
> If we don't care about improved error messages for existing libvirt
> versions, we can just add a 'hint' field in QMP and let new libvirt
> use that:
> 
> diff --git a/qapi/qmp-dispatch.c b/qapi/qmp-dispatch.c
> index 935f9e159c..82eb823f1f 100644
> --- a/qapi/qmp-dispatch.c
> +++ b/qapi/qmp-dispatch.c
> @@ -132,9 +132,15 @@ static QObject *do_qmp_dispatch(QmpCommandList *cmds, QObject *request,
>  
>  QObject *qmp_build_error_object(Error *err)
>  {
> -    return qobject_from_jsonf("{ 'class': %s, 'desc': %s }",
> -                              QapiErrorClass_str(error_get_class(err)),
> -                              error_get_pretty(err));
> +    const char *hint = error_get_hint(err);
> +    if (hint)
> +        return qobject_from_jsonf("{ 'class': %s, 'desc': %s, 'hint': %s }",
> +                                  QapiErrorClass_str(error_get_class(err)),
> +                                  error_get_pretty(err), hint);
> +    else
> +        return qobject_from_jsonf("{ 'class': %s, 'desc': %s }",
> +                                  QapiErrorClass_str(error_get_class(err)),
> +                                  error_get_pretty(err));
>  }
>  
>  /*
> 
> 
> there's no error_get_hint method right now, but its impl is essentially
> the same as error_get_pretty.
> 
> 
> If, however, we want to get better error messages for existing libvirt,
> then, we should do:
> 
> diff --git a/qapi/qmp-dispatch.c b/qapi/qmp-dispatch.c
> index 935f9e159c..bf6f92375a 100644
> --- a/qapi/qmp-dispatch.c
> +++ b/qapi/qmp-dispatch.c
> @@ -132,9 +132,18 @@ static QObject *do_qmp_dispatch(QmpCommandList *cmds, QObject *request,
>  
>  QObject *qmp_build_error_object(Error *err)
>  {
> -    return qobject_from_jsonf("{ 'class': %s, 'desc': %s }",
> -                              QapiErrorClass_str(error_get_class(err)),
> -                              error_get_pretty(err));
> +    const char *hint = error_get_hint(err);
> +    const char *msg;
> +    if (hint) {
> +        msg = g_strdup_printf("%s: %s", error_get_pretty(), hint);
> +    } else {
> +        msg = g_strdup(error_get_pretty());
> +    }
> +    QObject *ret = qobject_from_jsonf("{ 'class': %s, 'desc': %s }",
> +                                      QapiErrorClass_str(error_get_class(err)),
> +                                      msg);
> +    g_free(msg);
> +    return ret;
>  }
>  
>  /*
> 
> Personally I'd just go for the first case and only care about new libvirts.

Yes I think that is the plan. And that's the reason for exceptional cases like
this patch, for older libvirts (which of course is subjective).

Fam

Daniel P. Berrangé <berrange@redhat.com> writes:

> On Fri, Jun 01, 2018 at 05:18:35PM +0800, Fam Zheng wrote:
>> When hot-plugging a block device fails due to image locking errors,
>> users won't see the helpful 'Is another process using the image?'
>> message in QMP because currently the error hint is not carried over
>> there.
>> 
>> Even though extending QMP to include hint is a conceivably easy task,
>> Libvirt will need some change to consume that data.
>> 
>> Before that is fully sorted out, let's just do the easy fix by joining
>> the two lines.
>
> There are many places in QEMU which uses error hints and these are all
> invisible to libvirt. Arbitrarily picking one hint to remove, while
> leaving everything else unfixed is not a very satisfactory approach.
>
> If QEMU passes the hint in QMP, it is trivial for libvirt to be changed
> to append the hint when reporting its own error message, so can we just
> focus on fixing the root cause instead of special casing file-posix.c

Intended use of hints according to error.h:

 * Intended use is adding helpful hints on the human user interface,
 * e.g. a list of valid values.  It's not for clarifying a confusing
 * error message.

I admit this guidance is widely ignored.

When used as intended, the hints need not make any sense in QMP!
Consider this example in qemu-option.c:

        error_setg(errp, QERR_INVALID_PARAMETER_VALUE, name,
                   "a non-negative number below 2^64");
        error_append_hint(errp, "Optional suffix k, M, G, T, P or E means"
                          " kilo-, mega-, giga-, tera-, peta-\n"
                          "and exabytes, respectively.\n");

The suffixes are only available in the human interface.

Aside: we have lots of code consuming input from both QMP and HMP / CLI.
The error reporting is generally atrocious for at least one of the two.

Perhaps we could use separate functions for providing syntax hints and
for clarifying confusing error messages.  Patches welcome, but they
better convert all existing uses.

On Thu, Jun 07, 2018 at 03:20:24PM +0200, Markus Armbruster wrote:
> Daniel P. Berrangé <berrange@redhat.com> writes:
> 
> > On Fri, Jun 01, 2018 at 05:18:35PM +0800, Fam Zheng wrote:
> >> When hot-plugging a block device fails due to image locking errors,
> >> users won't see the helpful 'Is another process using the image?'
> >> message in QMP because currently the error hint is not carried over
> >> there.
> >> 
> >> Even though extending QMP to include hint is a conceivably easy task,
> >> Libvirt will need some change to consume that data.
> >> 
> >> Before that is fully sorted out, let's just do the easy fix by joining
> >> the two lines.
> >
> > There are many places in QEMU which uses error hints and these are all
> > invisible to libvirt. Arbitrarily picking one hint to remove, while
> > leaving everything else unfixed is not a very satisfactory approach.
> >
> > If QEMU passes the hint in QMP, it is trivial for libvirt to be changed
> > to append the hint when reporting its own error message, so can we just
> > focus on fixing the root cause instead of special casing file-posix.c
> 
> Intended use of hints according to error.h:
> 
>  * Intended use is adding helpful hints on the human user interface,
>  * e.g. a list of valid values.  It's not for clarifying a confusing
>  * error message.
> 
> I admit this guidance is widely ignored.

Perhaps if we rename the function "error_append_hmp_hint" it would
make it obvious this is targetted at CLI users, and not QMP users,
and so encourage people to write better initial messages  ?

> 
> When used as intended, the hints need not make any sense in QMP!
> Consider this example in qemu-option.c:
> 
>         error_setg(errp, QERR_INVALID_PARAMETER_VALUE, name,
>                    "a non-negative number below 2^64");
>         error_append_hint(errp, "Optional suffix k, M, G, T, P or E means"
>                           " kilo-, mega-, giga-, tera-, peta-\n"
>                           "and exabytes, respectively.\n");
> 
> The suffixes are only available in the human interface.
> 
> Aside: we have lots of code consuming input from both QMP and HMP / CLI.
> The error reporting is generally atrocious for at least one of the two.
> 
> Perhaps we could use separate functions for providing syntax hints and
> for clarifying confusing error messages.  Patches welcome, but they
> better convert all existing uses.

Regards,
Daniel