Libguestfs - Feb 2020 - Re: Plans for nbdkit 1.18 release?

Hi Eric,

nbdkit 1.16 was released over 3 months ago, and there has been quite a
lot of upstream development since then, so it could be about time for
a new stable release.  Anything in particular that you would like to
get in to 1.18?  Or anything we've added that you have reservations
about supporting long-term?

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top

On 2/20/20 3:37 PM, Richard W.M. Jones wrote:
> Hi Eric,
> 
> nbdkit 1.16 was released over 3 months ago, and there has been quite a
> lot of upstream development since then, so it could be about time for
> a new stable release.  Anything in particular that you would like to
> get in to 1.18?  Or anything we've added that you have reservations
> about supporting long-term?
My biggest worry is whether we want to make python API version 2 plugins 
support an optional flags parameter.  I think we decided that for 
version 1 plugins, making .zero's may_trim argument optional was not 
worth it.  But especially given that things like .pread currently always 
pass a flags=0 parameter, making it optional for API version 2 is still 
worth pursuing.  As you recall, I did post potential glue code for 
optional parameters, but it was different than the code we eventually 
took when adding API version 2 support, and I have not yet had time to 
rebase the salvageable parts of my patches.

On the other hand, releasing 1.18 with mandatory flags= parameter in 
python plugins, and later relaxing it when we figure out the glue code, 
shouldn't be a problem.  It is not backwards incompatible to make a 
once-required parameter become optional.  So I don't see it as holding 
up a release.

My proposal to add an NBD_INFO_INIT_STATE extension is still pending on 
multiple fronts (approval at the NBD spec, and a rewrite of both qemu 
and nbdkit patches to address review comments); I'm not worried if that 
misses 1.18.

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

On Thu, Feb 20, 2020 at 05:03:18PM -0600, Eric Blake
wrote:
> On 2/20/20 3:37 PM, Richard W.M. Jones wrote:
> >Hi Eric,
> >
> >nbdkit 1.16 was released over 3 months ago, and there has been quite a
> >lot of upstream development since then, so it could be about time for
> >a new stable release.  Anything in particular that you would like to
> >get in to 1.18?  Or anything we've added that you have reservations
> >about supporting long-term?
> 
> My biggest worry is whether we want to make python API version 2
> plugins support an optional flags parameter.  I think we decided
> that for version 1 plugins, making .zero's may_trim argument
> optional was not worth it.  But especially given that things like
> .pread currently always pass a flags=0 parameter, making it optional
> for API version 2 is still worth pursuing.  As you recall, I did
> post potential glue code for optional parameters, but it was
> different than the code we eventually took when adding API version 2
> support, and I have not yet had time to rebase the salvageable parts
> of my patches.
I think making the flags parameter option, ie this:

def pread(h, buf, offset, flags=0):
def trim(h, count, offset, flags=0):

could be worthwhile, although as you say below it we could still
change this later.  I don't think the bitmasks are bad, since plenty
of standard Python APIs seem to take bitmasks, and they're also much
faster to handle since they can be passed almost directly to the C
API.
> On the other hand, releasing 1.18 with mandatory flags= parameter in
> python plugins, and later relaxing it when we figure out the glue
> code, shouldn't be a problem.  It is not backwards incompatible to
> make a once-required parameter become optional.  So I don't see it
> as holding up a release.
> 
> My proposal to add an NBD_INFO_INIT_STATE extension is still pending
> on multiple fronts (approval at the NBD spec, and a rewrite of both
> qemu and nbdkit patches to address review comments); I'm not worried
> if that misses 1.18.
OK, thanks!  I'll have a go at some release notes next week which
should give us a clearer idea of what's new/changes.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top

Eric:

Did you want to take this one any further?  It might be one that we
save for > 1.18:

https://www.redhat.com/archives/libguestfs/2020-February/thread.html#00206

Another thing I've been thinking about for some time is splitting
.config_complete into .config_complete + .get_ready (new name TBD).
At the moment .config_complete is both the place where we finish
processing config, and also the last chance we get to set things up
before the server forks.  Of course such a change would not be
material — .get_ready would always be run immediately after
.config_complete — but it cleans up the API a little.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top