[Libguestfs] nbdkit design: varying the rate limit parameter

[Eric Blake]

On 3/26/19 11:13 AM, Richard W.M. Jones wrote:
> Hi Eric,
> 
> We may have our first user (Tomas, CC'd) of the rate filter to limit
> NBD connections.  As you recall it lets you do commands like:
> 
>   nbdkit --filter=rate memory size=64G rate=10M
> 
> to limit network bandwidth to 10 Mbps.  However a twist is that he
> needs to vary the parameter while nbdkit is running in response to a
> UI, and we haven't really thought about that before.
> 
> In the grand and noble tradition of qemu we don't actually systematize
> parameters.  For the server they are just (key, value) strings.  (It's
> even possible for filters to modify plugin parameters, thankfully
> nothing does that.)
> 
> The only filter we have which does anything similar is the error
> filter, where the error-file parameter lets you enable and disable the
> filter at runtime based on the presence of a file.
> 
>   rm -f /tmp/inject
>   nbdkit --filter=error file disk.img error-rate=100%  error-file=/tmp/inject
>   sleep 60; touch /tmp/inject

And interesting that it is the presence (and not the contents) of that file.

> 
> I think our options are:
> 
> * One-time hack in the rate filter.
> 
> * One-time hack in the rate filter, but make it compatible with a
>   possible future revision of parameter handling.  eg: If we decided
>   that "rate:file" would in future mean "read ‘rate’ parameter from a
>   file" then we could add this as a simple parameter now but
>   systematize it in future.

So if I understand the proposal, we'd use "name:type" (where :type is
optional and defaults to :string), so that in the future we can define
other valid types (:file meaning to read from a file, and pay attention
to whether that file changes at runtime).  It would also mean we could
add types such as :int or :size to get nbdkit to do sanity checking that
a string is indeed parseable as a particular type of integer, or :bool
to automatically use nbdkit_parse_bool, rather than having to open-code
those checks in each plugin/filter using a parameter with those types.

> 
> * Systematize parameters.  This would require a great deal of work and
>   likely another version of the API.  (I pushed a note into the TODO
>   file for this.)

Have we documented any restrictions on what forms a valid parameter
name? If we don't allow ':' in current parameter names, that's nicer
(because we can add the extension of 'name:type') than if our new
interpretation of ':' could interfere with existing plugin's parameter
names.  Then again, abusing 'name:type' instead of having an actual
struct may be a reason why a v3 protocol that uses an actual struct
could be easier to work with.

> If we went all the way and allowed parameter values to change, would
> this be triggered only by simple file changes, or would we want an
> administration interface to the server?  (a la QMP)

It sounds like a lot of work to get an administration interface,
compared to just stating that a particular dynamic value will be
obtained by re-reading a given file name each time the parameter's value
is needed at runtime.

> 
> But I wonder if you have any better ideas?
> 
> Rich.
> 

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3226
Virtualization:  qemu.org | libvirt.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/libguestfs/attachments/20190328/6cabfc89/attachment.sig>