qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Juan Quintela <quintela@redhat.com>
To: Daniel Henrique Barboza <danielhb@linux.vnet.ibm.com>
Cc: Markus Armbruster <armbru@redhat.com>,
	qemu-devel@nongnu.org, dgilbert@redhat.com
Subject: Re: [Qemu-devel] [PATCH v2] Changing error message of QMP 'migrate_set_downtime' to seconds
Date: Tue, 21 Feb 2017 14:54:04 +0100	[thread overview]
Message-ID: <87ino3odj7.fsf@emacs.mitica> (raw)
In-Reply-To: <e9388bc4-2c50-0656-e140-b5478f35237b@linux.vnet.ibm.com> (Daniel Henrique Barboza's message of "Tue, 21 Feb 2017 10:31:25 -0300")

Daniel Henrique Barboza <danielhb@linux.vnet.ibm.com> wrote:
> On 02/21/2017 06:02 AM, Markus Armbruster wrote:
>> Daniel Henrique Barboza <danielhb@linux.vnet.ibm.com> writes:
>>
>>> The previous error message was displaying the values in miliseconds,
>>> being misleading with the command that accepts the value in seconds:
>>>
>>> { "execute": "migrate_set_downtime", "arguments": {"value": 3000}}
>>> {"error": {"class": "GenericError", "desc": "Parameter 'downtime_limit'
>>> expects an integer in the range of 0 to 2000000 milliseconds"}}
>>>
>>> This patch changes it to '2000 seconds' to keep consistency with
>>> the expected parameter. The macro 'QERR_INVALID_PARAMETER_VALUE'
>>> was changed for a regular string that allows the use of the
>>> MAX_MIGRATE_SET_DOWNTIME as a parameter, instead of hardcoding
>>> the value in the error message.
>>>
>>> Signed-off-by: Daniel Henrique Barboza <danielhb@linux.vnet.ibm.com>
>>> ---
>>>   migration/migration.c | 12 ++++++++----
>>>   1 file changed, 8 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/migration/migration.c b/migration/migration.c
>>> index c6ae69d..c05e764 100644
>>> --- a/migration/migration.c
>>> +++ b/migration/migration.c
>>> @@ -49,6 +49,9 @@
>>>    * for sending the last part */
>>>   #define DEFAULT_MIGRATE_SET_DOWNTIME 300
>>>   +/* Maximum migrate downtime set to 2000*1000 miliseconds */
>>> +#define MAX_MIGRATE_SET_DOWNTIME (2000 * 1000)
>>> +
>>>   /* Default compression thread count */
>>>   #define DEFAULT_MIGRATE_COMPRESS_THREAD_COUNT 8
>>>   /* Default decompression thread count, usually decompression is at
>>> @@ -843,10 +846,11 @@ void qmp_migrate_set_parameters(MigrationParameters *params, Error **errp)
>>>           return;
>>>       }
>>>       if (params->has_downtime_limit &&
>>> -        (params->downtime_limit < 0 || params->downtime_limit > 2000000)) {
>>> -        error_setg(errp, QERR_INVALID_PARAMETER_VALUE,
>>> -                   "downtime_limit",
>>> -                   "an integer in the range of 0 to 2000000 milliseconds");
>>> +        (params->downtime_limit < 0 ||
>>> +         params->downtime_limit > MAX_MIGRATE_SET_DOWNTIME)) {
>>> +        error_setg(errp, "Parameter 'downtime_limit' expects an integer in "
>>> +                         "the range of 0 to %d seconds",
>>> +                         MAX_MIGRATE_SET_DOWNTIME / 1000);
>>>           return;
>>>       }
>>>       if (params->has_x_checkpoint_delay && (params->x_checkpoint_delay < 0)) {
>> Isn't this wrong for QMP migrate-set-parameters?  There, the unit is
>> milliseconds, i.e. the new error message is as wrong as the old one is
>> for migrate_set_downtime.
>
> Actually the unit for migrate-set-parameters, as seen by the caller,
> is seconds. The underlying logic receives the input and multiplies it
> by 1000 in qmp_migrate_set_downtime().
>>
>> I'm afraid you need to fix the error message in
>> qmp_migrate_set_downtime().  If you assume qmp_migrate_set_parameters()
>> fails only in one way, replace its error object by one with a better
>> message[*].  If you'd rather not assume, you need to refactor things so
>> that each place can set the downtime and create an appropriate error on
>> failure.
>
> There is at least one similar usage of this error message just
> above this code in max_bandwidth param. Perhaps a new
> function/macro to deal with these cases is justified.
>
>>
>> We might want to check other command wrappers that translate units.
>>
>> Time units are a hopeless mess in QMP.  We should've enforced uniform
>> usage of either seconds or nanoseconds.  The latter to placate
>> irrational fear of floating-point[**].
>
> I agree that my patch doesn't make it much better. I just set the
> error message to be in seconds to be consistent with the user input,
> but the code now feels 'awkward' when you do a verification
> in milliseconds and deliver the error message in seconds.
>
> One thing that can be done is to make migrate-set-downtime to
> accept milliseconds instead of seconds. I wasn't willing at first to
> change the migrate-set-downtime API because of an error
> message, however it really feels like the right thing to do here.
> Specially when you consider that the default value of this parameter,
> set by DEFAULT_MIGRATE_SET_DOWNTIME, is 300 - a value that
> in theory the user shouldn't be able to set in the API.

libvirt and users use the API, I don't see how to change it in an easy
way :-(

I think that the better way we can do is change the error message and be
done with it.

Later, Juan.

  reply	other threads:[~2017-02-21 13:54 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-20 16:03 [Qemu-devel] [PATCH v2] Changing error message of QMP 'migrate_set_downtime' to seconds Daniel Henrique Barboza
2017-02-21  9:02 ` Markus Armbruster
2017-02-21 13:31   ` Daniel Henrique Barboza
2017-02-21 13:54     ` Juan Quintela [this message]
2017-02-21 14:15     ` Markus Armbruster
2017-02-21 14:32       ` Dr. David Alan Gilbert
2017-02-21 15:47         ` Markus Armbruster
2017-02-21 21:49           ` Daniel Henrique Barboza

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=87ino3odj7.fsf@emacs.mitica \
    --to=quintela@redhat.com \
    --cc=armbru@redhat.com \
    --cc=danielhb@linux.vnet.ibm.com \
    --cc=dgilbert@redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).