Re: [Qemu-block] nbd oldstyle negotiation

[Eric Blake]

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:

newstyle client => nbdkit nbd plugin => oldstyle server
oldstyle client => nbdkit nbd plugin => newstyle server

(well, that plugin could be enhanced to support IP addresses, rather 
than just Unix sockets, but that's a topic for another mailing list)

But I'm open to counter opinions on whether we need to be more 
conservative, and will not rip things out without at least getting 
opinions from others on how aggressive or conservative the switchover 
should be.

> from nbd spec:
>   ... the old style negotiation is now no longer developed; starting 
> with version 3.10 of the reference implementation, it is also no longer 
> supported.
>
> it's unsupported, I think it's ok to drop it. I can create patches, if 
> you agree.

If you want to create patches, that's also fine by me.

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