[libvirt] [PATCH v4 7/7] blockjob: allow forcing of bytes scale in virsh

[Eric Blake]

On 09/12/2014 06:32 AM, Peter Krempa wrote:
> On 09/12/14 05:55, Eric Blake wrote:
>> Take the previous patch one step further.  In addition to
>> automatically selecting byte mode with fallback if the
>> user's result would be rounded, we also want to give the
>> user a way to guarantee byte mode even if rounding is not
>> required, with no fallback if the remote side doesn't
>> support byte mode.  This way, virsh can be used to more
>> fully test the impact of setting the bytes flag.
>>
>> * tools/virsh-domain.c (blockJobBandwidth): Adjust return type and
>> check for --bytes flag.
>> (cmdBlockCommit, cmdBlockPull, cmdBlockJob): Add --bytes flag.
>> (cmdBlockCopy): Likewise, and adjust caller.
>> (blockJobImpl): Adjust caller.
>> * tools/virsh.pod (blockcommit, blockcopy, blockpull, blockjob):
>> Document this.
>>
>> Signed-off-by: Eric Blake <eblake at redhat.com>
>> ---
>>  tools/virsh-domain.c | 57 ++++++++++++++++++++++++++++++++++------------------
>>  tools/virsh.pod      | 48 +++++++++++++++++++++----------------------
>>  2 files changed, 61 insertions(+), 44 deletions(-)
>>
>> diff --git a/tools/virsh-domain.c b/tools/virsh-domain.c
> 
> Whoah, this is getting a bit too complex IMHO for a simple task.
> 
> How about not doing any automagic switching and if the user specifies
> the --bytes flag then it would be passed and otherwise just the old
> MiB/s value. The --bytes flag could also parse the value as a scaled
> integer then.

So if I understand your proposal,

old call, in MiB:
 blockjob $dom $disk --bandwidth 1

invalid (attempt to scale, but no --bytes present)
 blockjob $dom $disk --bandwidth 1B

new call, in bytes (awfully small value!), fails if server doesn't work
 blockjob $dom $disk --bandwidth 1 --bytes

new call, in bytes, but using scaling to match old call
 blockjob $dom $disk --bandwidth 1M --bytes

and no automatic fallbacks.  I can live with that, but it means ditching
patches 5 and 6, and posting a complete alternative.  Give me a couple
days (I've got another project I'm working at the moment, for image
allocation high-watermark reporting), and we'll compare the two approaches.

> 
> This would allow to drop a lot of the complexity while still allow to
> use the new flags as we unfortunately have to stick with MiB/s in virsh.
> That on the other hand doesn't force us to do overly complex logic that
> can be left on the operator.

Any other opinions on whether virsh should be user-friendly (automagic
fallback) vs. more literal exposure (no scaled input without --bytes,
but maps closer to API)?

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 539 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20140912/0f1f891d/attachment-0001.sig>