[Libguestfs] [PATCH nbdkit 0/2] Add new retry filter.

[Nenad Peric]

A theoretical way to test this against any other protocol is to have a
firewall rule which can be triggered locally which just drops the traffic
and then re-enables the traffic in a while (short or long, can be
decided/tweaked).
This way, there is no need to think about which protocol is used, when we
kill the connectivity.
The only consideration could probably be that the dropped connections would
cover only the ports we need.
To reduce the size of the hammer :)


*Nenad Perić*

PRINCIPAL SOFTWARE ENGINEER

Red Hat - Migration Engineering

nenad at redhat.com

<http://redhat.com>


On Thu, Sep 19, 2019 at 1:34 PM Richard W.M. Jones <rjones at redhat.com>
wrote:

> This is a retry filter implementation as outlined here:
> https://www.redhat.com/archives/libguestfs/2019-September/msg00167.html
>
> It is only lightly tested.  One way to test it is to try an SSH copy
> (see the commit message for patch 2/2), and in the middle of the copy
> kill the per-connection sshd on the remote machine.  You will see that
> the copy recovers after a few seconds.  Add the nbdkit -v option to
> see some useful messages from the filter:
>
>   ...
>   nbdkit: ssh[1]: debug: ssh: pread count=2097152 offset=216006656
>   nbdkit: ssh[1]: error: read failed: Socket error: Connection reset by
> peer (-1)
>   nbdkit: ssh[1]: debug: retry 1: original errno = 5
>   nbdkit: ssh[1]: debug: waiting 2 seconds before retrying
>   nbdkit: ssh[1]: debug: ssh: reopen
>   nbdkit: ssh[1]: debug: close
>   nbdkit: ssh[1]: error: cannot close file: Socket error: Connection reset
> by peer
>   nbdkit: ssh[1]: debug: ssh: open readonly=0
>   nbdkit: ssh[1]: debug: opened libssh handle
>   nbdkit: ssh[1]: debug: ssh: pread count=2097152 offset=216006656
>   ...
>
> It really needs an actual test, which is tricky to implement.  My
> thinking currently is that a custom (sh) plugin is the way to go, but
> it would also be nice to test curl/ssh/vddk with this filter -- if
> anyone has any suggestions on how to do that ...
>
> This patch will probably conflict with Eric's series here:
> https://www.redhat.com/archives/libguestfs/2019-September/msg00180.html
> but that shouldn't be too hard to fix up.
>
> Rich.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/libguestfs/attachments/20190919/8d50a3ed/attachment.htm>