Re: [Qemu-devel] nbd oldstyle negotiation

["Daniel P. Berrangé" <berrange@redhat.com>]

On Thu, Aug 16, 2018 at 02:56:10PM -0500, Eric Blake wrote:
> On 08/16/2018 02:02 PM, Vladimir Sementsov-Ogievskiy wrote:
> > Hi Eric!
> > 
> > There is a small problem with our qemu-nbd cmdline interface: people
> > forget to use option -x or don't know about it and face into problems
> > with old protocol version. One of may colleagues after such situation
> > (because of this option, he could not use utility nbd-client, which
> > doesn't support old version) asked me to add comments about version
> > selection by -x option into --help of qemu-nbd. And really, it's not an
> > obvious interface solution...
> > 
> > Now I think, should not we use new version by default? Or, even drop old
> > version support at all? Anybody uses it?
> 
> nbdkit 1.3 switched its default to newstyle (Jan 2018):
> https://github.com/libguestfs/nbdkit/commit/b2a8aecc
> https://github.com/libguestfs/nbdkit/commit/8158e773
> 
> and you are correct that nbd 3.10 dropped oldstyle long ago (Mar 2015):
> https://github.com/NetworkBlockDevice/nbd/commit/36940193
> 
> oldstyle is severely lacking in features (it can't do TLS or efficient
> sparse file handling, for example).  Do we need a formal qemu deprecation
> period (where you still get oldstyle if -x was not used, but a nice big
> warning) before flipping the default in 3.2/3.3 [1], or are we okay flipping
> it in 3.1?
> 
> [1] Okay, I know that our new equally-arbitrary policy on when to bump qemu
> version number components means that we'll probably see 3.1 in 2018 then 4.0
> in 2019, rather than 3.2.
> 
> And, if we switch the default now (which I am in favor of), do we want to
> add a -o switch to still make it possible to select oldstyle for a couple
> more releases in case someone was relying on it?  Then again, if you have to
> amend your script to use -o to keep things from breaking, why not just amend
> your setup to use newstyle?
> 
> My personal preference: completely drop oldstyle support from qemu, for 3.1,
> with no deprecation period. Do so by making '-x ""' the default for any
> qemu-nbd command line that did not otherwise specify an export name.  If
> someone still needs interoperability, they can use nbdkit in the middle,
> which will still support oldstyle, and provides a plugin for connecting:

So the key question is if the server switches to newstyle with "" export
name, what versions of qemu client will cease to work. Originally the QEMU
client would refuse to use new style protocol if not export name was given.

I fixed that in

commit 69b49502d8b7b582af79fac5bef7b7ccc2dc9c1e
Author: Daniel P. Berrange <berrange@redhat.com>
Date:   Wed Feb 10 18:41:10 2016 +0000

    nbd: use "" as a default export name if none provided
    

So if we mandate new style in the server then we break compat with any
QEMU client that is < 2.6.0

I think that is acceptable as this point in time, as that'll be about
3 years old by time 3.1 comes out.


Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|