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