Starting with nbdkit 1.16, Python >= 3.3 will be required.
Python 2 reaches end of life on 2020-01-01:
https://python3statement.org/
https://pythonclock.org/
Debian oldoldstable and RHEL 7 have Python 3.4 and 3.6 respectively,
so it seems pointless to try to support Python < 3.3 which lacked
This patch proposes to drop support for Python 2 in nbdkit.
Rather than abruptly drop it everywhere, my proposal is that we point
people to nbdkit 1.14 (the current stable version) if they want to
continue with Python 2 plugins, while gently reminding them of the
upcoming Python 2.7 end of life
On Wed, Sep 11, 2019 at 02:57:50PM +0100, Richard W.M. Jones wrote:
> On Wed, Sep 11, 2019 at 08:48:28AM -0500, Eric Blake wrote:
> > On 9/11/19 5:40 AM, Richard W.M. Jones wrote:
> > > Very much a work in progress as there are still many tests using
> > > qemu-io which are candidates for
On 9/11/19 2:42 PM, Richard W.M. Jones wrote:
> Starting with nbdkit 1.16, Python >= 3.3 will be required.
>
> Python 2 reaches end of life on 2020-01-01:
> https://python3statement.org/
> https://pythonclock.org/
>
> Debian oldoldstable and RHEL 7 have Python 3.4 and 3.6 respectively,
> so it
Similar to --no-sr, it can be handy for testing a client
implementation to have a server that can easily be forced into older
behaviors, without having to recompile a one-off hack into a server or
dig up an older server binary that lacked a newer feature.
To see the patch in action, try things
The NBD protocol states that servers may still choose to honor various
NBD_OPT_* from a client that did not reply with
NBD_FLAG_C_FIXED_NEWSTYLE; however, for integration testing purposes,
it's a lot nicer if we reject everything except NBD_OPT_EXPORT_NAME
from such a client (for example, with
This is similar to the recent --no-sr option - it's a change that is
unlikely to ever be used except by someone testing whether a client is
compliant to the protocol, but in that niche case, it can be quite
handy (it's a lot nicer to be able to purposefully cripple a server
from the command line
Ultimately, I'd like to add a unit test covering our recent fix for
handling globals from consecutive -c, but let's start with a simple
test that --help output is sane. Sanity includes a mention of the man
page for more details (similar to nbdkit --help, although I couldn't
figure out how to make
nbdsh has some advantages over qemu-io:
- scriptable
- allows us to more finely control NBD commands, such as
making subsector-sized requests and controlling how
many commands are sent on the wire
- can write controlled patterns
- can read NBD export flags
---
README
Very much a work in progress as there are still many tests using
qemu-io which are candidates for conversion.
You'll notice at the end of test-full.sh that the new test has some
duplicated code which looks as if it ought to be refactored into a
Python function. When I tried to do that, I got
On Wed, Sep 11, 2019 at 08:48:28AM -0500, Eric Blake wrote:
> On 9/11/19 5:40 AM, Richard W.M. Jones wrote:
> > Very much a work in progress as there are still many tests using
> > qemu-io which are candidates for conversion.
> >
> > You'll notice at the end of test-full.sh that the new test has
On 9/11/19 5:40 AM, Richard W.M. Jones wrote:
> Very much a work in progress as there are still many tests using
> qemu-io which are candidates for conversion.
>
> You'll notice at the end of test-full.sh that the new test has some
> duplicated code which looks as if it ought to be refactored
On 9/11/19 5:40 AM, Richard W.M. Jones wrote:
> nbdsh has some advantages over qemu-io:
>
> - scriptable
>
> - allows us to more finely control NBD commands, such as
>making subsector-sized requests and controlling how
>many commands are sent on the wire
>
> - can write controlled
13 matches
Mail list logo
